Re: CFD (Call for discussion): packaging streamlining for Samba 3.0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John H Terpstra wrote:
> On Wed, 21 May 2003, Gerald (Jerry) Carter wrote:
>
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>On Wed, 21 May 2003 [email protected] wrote:
>>
>>
>>>Some questions first:
>>>
>>>1. How does the Samba team want people to get samba packages?
>>>a)build from source tarball always (./configure; make; sudo make install)
>>>b)Always use packages provided by the OS/distro and only security updates
>>>c)Packages provided by the OS/distro and updated packages made available
>>>3rd-party.
>>>d)Packages provided by the OS/distro and updates via packages made from
>>>the source tarball.
>>
>>The packages are provided as a service.  The source is the
>>authoritative means of installing.  However, note that the
>>percentage of prepackaged Samba releases (RPMs, etc..)
>>is a respectable amount even when compared to source tarballs.
>
>
> Right now, there is NO consistency in how Samba for Linux is packaged and
> integrated into the OS. If we do NOT lay down standards (and document them
> through the LSB) then we are in essence creating an administrative hell
> for support companies. This is essentially a question that affects our
> end users. Do we want to help them by providing a consistent cross
> distribution set of capabilities _or_ not?
>

Clearly it would have samba packaged consistently across distributions,
but the question is, what aspects of consitency really matter?

> Samba-Team members are geeks, who CAN and WILL build samba any-which-way.
> And that is Ok, in fact, it is to be encouraged. Binary packages are NOT
> suitable for those who want to play with nirvana.
>
> Debian users are geeks who will as much as possible do things in ways
> exciting and different. Binary packages are like hell on earth to the
> revolutionary spirit. On the other hand, much time is also spent in
> helping Debian users over their learning curve - time we do not have a lot
> of! But again, we should let the revolutionaries do their thing. To do
> otherwise is futile and inflamatory.
>

I think actually in most cases, Debian packaging rules are more strict
than most other distros ...

> RPM binary packages are for those who want to use Samba and Linux, not for
> those who want to explore and break them. Whether we like it or not, the
> vast majority of our user base fits into that mould. They want to install
> Samba and have it work exactly the same on all the Linux platforms they
> have on site.
>
> I know of sites that have SuSE, Mandrake and Red Hat because they have
> purchased applications from different vendors who support only one Linux
> distribution. Even though these platforms are supposedly LSB compliant,
> Samba on each is completely different in terms of file system layout,
> components available (Red Hat does NOT install SWAT by default), support
> tools and utilities, and in respect of actual Samba capabilities.
>

Sure, they will be different, because the LSB doesn't cover very much
that differentiates samba packages. I mean, in most cases samba owns
files in /etc/samba, /usr/share/samba, /usr/lib/samba, and this is all
LSB-compliant.

And I don't think swat should be installed by default (just like telnet,
rsh, rcp etc shouldn't either) unless it uses ssl by default. And you
know my other issues with SWAT. I would actually consider not even
building swat packages by default and let users use ksambaplugin instead ...

> We have a choice, just like we always have had.
>
> Do we want to help OUR users to achieve a level of consistency that will
> make their lives easier, or do we take a Pontius Pilot attitude and
> declare that we are NOT concerned for their well being, that is the
> responsibility of their Linux distro vendor?
>

Well, in some cases we are a representative of the Linux distro vendor
anyway.

> Bear in mind, that if we choose to go to battle for our users then we are
> going to find conflict with Linux companies who still follow a
> busineess philosophy that is based on the evangelical heart throb of
> Frank Sinatra, who in tumulteous belching blasted into the minds of a
> revolutionary world, "I did it my way!"
>

Well, considering that the only packages that are supplied by the samba
team are the RH packages, which would probably give over 200 warnings
with rpmlint (current Mandrake packages still get about 30 warnings due
to things like smbwrapper.so which rpmlint thinks is a library, but
there are no unnecessary warnings), a distro doing it their way is
probably preferable at present, without any other worthwhile guidelines.

>
>>>2. How do packagers want users to get samba packages?
>>>(same potential answers).
>>>
>>>Since I maintain the Mandrake packaging in samba_2_2 and samba_3_0, as
>>>well as maintainting samba3 in Mandrake, and assisting with samba
>>>(currently 2.2.x) in Mandrake, my main goal is avoiding duplicating my
>>>own work (merging spec files is not fun!). So, the Mandrake spec files
>>>in samba CVS and Mandrake CVS are interchangeable (normally just
>>>slightly out of sync).
>>
>>The RedHat packages have been a philosphical point that
>>several team members feel lvery strongly about (single package
>>for all Samba components).  Don't ask me why RedHat is the only
>>one we choose to do this way.  I'm just living in the rut of
>>history.
>
>
> Red Hat is NOT the only company that splits samba into component packages,
> all Linux distros do that now. The Samba-Team is out of step here. Long
> ago I gave in to this. Caldera OpenLinux, Mandrake, Red Hat, SuSE,
> TurboLinux and others have long split Samba into separate packages.
> Resistence is futile. We continue to proide a single package binary only
> for Red Hat Linux.
>
> My dispute over the current practice is NOT over the splitting up, it is
> over the fact that packager does it differently - there are no standards.
> The only organisation that stands any chance of affecting a standard is
> the Samba-Team. If we create a packaging standard, then we need to get
> commitment to it, or else we are just plainly wasting our time.
>
>
>>since I have no affiliation with a linux distro vendor, the
>>main goal is to provide RPMs for a significant portion of users
>>at the time of release of the source distribution.
>
>
> I believe that we should cease and desist from providing any binary
> packages for any Linux distribution that will not actively work with us so
> that as a minimum our packages and theirs are identical. What we have done
> over the years has been a cause of irritation to our users as well as to
> Red Hat. I am tired of this warfare - and that is why I gladly surrendered
> the Red Hat packaging to Jerry Carter.
>
> I will gladly work with any distro who want our assistance. If they don't
> - then let them sort it out themselves. We do not have the resources to
> battle this any longer.
>

I for one don't see why the biggest Linux distro can't afford to support
their own samba packages, wasting developer time that could be better
spent on features that would help everyone ...

>
>>>3. For RPM-based linux distros, is it worthwhile investigating whether
>>>one spec file could be adapted to work across most rpm-based distros, so
>>>that the user could always: $ rpm -ta samba-3.0.tar.bz2 ?
>>>
>>>This may be feasible, it may not be (we might be pusing the limits of
>>>the available conditionals in rpm), and if it is it will be a
>>>considerable amount work, and could lose features currently present in
>>>some.
>>
>>Where is Mr. Terpstra?
>
>
> We should provide NO more than three RPM build systems:
> 	1. LSB compatible (for SuSE)

Are you implying that no other distro's are LSB compatible?

> 	2. Red Hat compatible (if they want us to work with them)
> 	3. Mandrake
>
> Each uses differing variants of RPM, cross platform unification is not
> even a pipe dream away.
>

Different releases of the same distro use differing variants of rpm (as
the problems with dependencies required by the latest RH packages show).
This however doesn't mean it's any more difficult to support multiple
distro's easily (speaking as someone who maintains packages that build
from Mandrake 7.2 all the way through cooker >9.1).

> I have NO allegiancies to ANY Linux distro - none pay my salary!
> Oops, what is a salary?
>
>
>
>>>4. Or should a single script be provided in the root of the source
>>>distribution that builds a package (via the existing packaging
>>>directories).
>
>
> We need to create a unified packaging standard first. Then we need to
> decide IF we can implement it in such a way that any admin can build a
> suitable binary package for his/her platform from a single script.
>

But what would the unified packaging standard cover? Names of init
scripts? Location of config files? Location of binaries? Locations of
libraries and plugins? Locations of non-binary files?

BTW, installing all binaries in sane locations would be a start. One
example is smbmount, which even though on many distributions this will
be used by non-root is included in SBINDIR instead of BINDIR (there may
be a few others too).

> I have played with this. I have had access to up to 8 different platforms
> at various times. My conclusion is - it can not be done without a lot more
> time investment than I have available.
>

But assuming there is someone already supporting most of those
platforms, it could be done cooperatively without significant effort
from those people.

>
>>>5. Should samba be packaged consistently? Many linux distributions have
>>>packaging standards, and they don't allow a single monolithic samba
>>>package, yet most linux distributions also differ in the packages
>>>provided. Is there any value in trying to standradise on packages?
>
>
> Split packages is a foregone conclusion - forget about fighting that one
> any longer.
>
> The battle (if there is to be one) has to be over consistency of
> implmentation and capabilities.
>
> We need to know why we are fighting that battle - if we choose to do so.
>
> I refuse to go to war with Linux distros just to achieve consistency!
> Forget that option!
>
> If there is to be a battle, then it has to be FOR the USER, AND to help
> reduce the support overhead that we currently carry. That is why I am
> updating the HOWTO after all. I care about our users, that is why I work
> so hard on the stuff I am involved in (stuff that sits at the outside
> edge of the Samba project).
>
>
>>>I think for most packagers, the worst would be to have to maintain two
>>>vastly sets of packages, those in the distribution, and those in the
>>>samba source ...
>
>
> Amen!
>
>
>>I'm not really convinced that things need to change.  John T. was really
>>the instigator here.  I was hoping he would pipe up by now with some
>>ideas.
>
>
> I think you have the feedback you asked for, and maybe a little more.
>

So, what needs to change?

FYI, these are the current packages we have in Mandrake cooker:
$ rpm -q --specfile
/mnt/buchanhome/bgmilne/downloads/source/cvs/mandrake/SPECS/samba/samba.spec
samba-2.2.8a-5mdk
samba-server-2.2.8a-5mdk
samba-client-2.2.8a-5mdk
samba-common-2.2.8a-5mdk
samba-doc-2.2.8a-5mdk
samba-swat-2.2.8a-5mdk
samba-winbind-2.2.8a-5mdk
nss_wins-2.2.8a-5mdk
libsmbclient0-2.2.8a-5mdk
libsmbclient0-devel-2.2.8a-5mdk
libsmbclient0-static-devel-2.2.8a-5mdk

Samba3 is quite similar, with the addition of the passdb-xml,
passdb-mysql and test (contains the torture target) subpackages.

Are there representatives from other distros here?

Regards,
Buchan

- --
|--------------Another happy Mandrake Club member--------------|
Buchan Milne                Mechanical Engineer, Network Manager
Cellphone * Work            +27 82 472 2231 * +27 21 8828820x202
Stellenbosch Automotive Engineering         http://www.cae.co.za
GPG Key                   http://ranger.dnsalias.com/bgmilne.asc
1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+0hxArJK6UGDSBKcRAoGGAKCKUewro8C7sG87FjT42kk6oz4PmwCgsg51
fmSmVNxmP7xN335wqWtUo3g=
=Tk4h
-----END PGP SIGNATURE-----

******************************************************************
Please click on http://www.cae.co.za/disclaimer.htm to read our
e-mail disclaimer.
******************************************************************