rcrsn51 wrote:If you install a Samba SERVER package, it will use whatever smb.conf was declared at compile-time. There is no conflict with an existing CLIENT smb.conf located elsewhere. For example, Samba-TNG keeps its smb.conf in an entirely different location and there are no problems.
There is some accuracy with what you say that I agree with and there is some logic here that I disagree with.
I did not build the packages, here, for SAMBA. Now that you have raise an issue, here let me clarify for all readers who might read this.
First, YES, all PUPs do come with a feature from the FULL SAMBA (SAMBA.ORG) service that has been associated with Linux for almost 20 years now. Further, CUPS and Full SAMBA have been in lock-step since the inception of CUPS. Those 2 groups has always worked together to bring about the services to the LInux community that they deliver. These are 2 very seasoned products which continue to deliver stable services to the LInux community.
SMBClient IS A FEATURE OF FULL SAMBA! And it is the one item that full SAMBA provides that exist in all PUPs.
What has happened in Puppyland, is that helpful people have produced some addtions to PUPs in the form of PET/SFSs for the "full" SAMBA product. They truly deserve my award for there work and effort in helping.
But, there appears to be a deliberate effort to work around the existing SMBclient and its folder use versus embracing in and putting it where it should be....in the SAMBA folder. I understand why this is done. It has to do with a current PET that is also distributed with PUPs (differeent topic) that uses the SMBclient.
So, what needs and should happen is that there should be a "base" guideline for all SAMBA PETs/SFSs such that they include/embrace/replace the existing SMBclient with the one that comes with the SAMBA.ORG SAMBA. This, in my humble opinion is the primary reason why SAMBA keeps getting overlooked/lost/corrupted/etc from not just release to release of PUPs, but also from the differening versions. (notwithstanding that there are external library changes which can affect an PET/SFS generation and use within PUPs).
Sorry @Rcrsn51, I do respect your work as you know, but this explanation you give is begging the issue as oppose to addressing it as it rightfully should be.
As reported, I fully intend to update the full SAMBA installation document, 1st, then I will set on the task of learnig how to compile and generate a SAMBA PET for 32bit PUP525 that takes into account a proper method of inserting itself into the system, without, these comfusing error messages that will mislead any newbie. (I have always felt that telling the user via a document to ignore explicit error messages is NOT an answer anyone should be conveying....but, until I can address it or until someone else steps forward and builds SAMBA 3.5.8 taking into account appropriately, we have a system whose messages are kinda misleading.)