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

On Mon, 26 May 2003, Buchan Milne wrote:

> > 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?

Package names, components that install be default, where they are located,
what capabilities are enabled at compile time, and much more.

Not having a standard makes life very confusing for inexperienced admins.
This generates a lot of traffic on the samba mailing lists. You well know
that, you try valiantly to help some of these confused souls.

> > 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 ...

Despite that we still see a lot of mail from Debian uses who find the
whole challenge of getting Samba configured rather perplexing.

> > 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

Not so, for years I personally built and supplied RPM packages for:
	Red Hat, TurboLinux, Caldera OpenLinux, SCO OpenServer, UnixWare,
	DEC Tru64. We also had team members provide packages for Solaris,
	HPUX, AIX.

I gave up due to time constraints. It's better to get the distros to
supply packages for their platforms. And it is best if distros do their
own support. The problem with this is that if they do that in isolation of
the samba-team then we lose essential user contact.

> 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.

Then maybe we should send all users who ask distro specific questions back
to their distro vendor. Maybe we should have a policy of NOT providing any
distro specific help? It would save a lot of time and would leave us far
fewer issues to address.

Like for example, I can't get SWAT to work: Answer: Contact your Linux
vendor.

Second example, I can't get CUPS to work: Answer: Contact your Linux
vendor.

Man that makes life easy! And it would really help our users also. (Not!).


> >>>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 ...

We agree!

> >>>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?

Not at all. Sorry if it sounded that way. Ask the FSF which distros are
compliant - I am not a certifying authority. :)

> > 	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).

Maybe we should just get rid of the entire ~samba/packaging tree. I
almost regret having put it there. It imposes a maintenance overhead that
has become very messy to deal with.

> > 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?

Yep, as well as build options (ie: configure) and support scripts.

> 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).

This one has been a political hot potatoe for years.

> > 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.

Mandrake and SuSE are an example of co-operation. Very few other vendors
(and I do NOT mean just Linux) have had any form of active interaction
with the Samba-Team.

> >>>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.

You will find that each distro has their own sib-package names, and that
the content of these varies in a big way. This is actually a strong
argument for sending ALL package and platform related querries back to the
vendor.

> Are there representatives from other distros here?

Good question!

- John T.
-- 
John H Terpstra
Email: [email protected]