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

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?

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.

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.

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?

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

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

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

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.

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.

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


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