Supporting distro re-packaging (Was: [sclug] Linux Apprentice Wanted !)

[Roland Turner SCLUG]

On Tue, 2006-11-07 at 11:10 +0000, Alex Butcher wrote:

> Agreed. I see similar complaints about Red Hat's modifications, which are
> done for similar reasons (i.e. to be able to provide a coherent base OS that
> properly integrates everything they ship).

Right.

> The problem, as I see it, is that many end-users and developers see 'Linux'
> as a single OS, when in truth, it isn't. Consequently, we have end-users
> trying to pull upstream packages that haven't been packaged according to the
> conventions of the distro they want to run it on, and getting in a pickle.

This is also a problem, but it isn't the one that Dew was complaining
about; his complaint was about people seeking help at apache.org for
debian.org builds. In this instance, I believe that the problem is his
unwillingess to learn to say "no" (or, "no, please build from source")
and to deal with the consequences.

> IMHO, the best approach is for upstream developers to provide well-formed
> native packages for the distros they wish to support (assuming, of course,
> that they're happy with non-developer users using their code at that stage
> in its development!) as well as the raw untargeted package.

Right; the immediate problem here is the enormous variety of package
formats in use and the fact that, as yet, no one format is suitable for
all. In this respect, Pieter is correct; had LSB gotten considerably
further along then it would be feasible for package authors to provide a
distribution-neutral well-formed package. This would not be a substitute
for the distro-native package (with automated config upgrade handling,
etc.) but would provide a means to solve both problems:

- apache.org could readily decline to offer support on $DISTRO's native
build, because there would be a straightforward way to switch to a
"supported" build.

- users who wished to install more recent versions than their distro
offers (outside of the distro's "not-yet-released"-equivalent: sid,
rawhide, ...) could do so with ease.

Note that, of course, solving this problem also brings back the whole
"in source form" problem. e.g. http://www.videolan.org/vlc/ offers
builds or instructions for 22 platforms! For package authors to avoid
this level of effort, source distribution is the only option. Granted, a
workable LSB approach could address a useful subset of this in one
binary build, at least for i386.

Further, whether or not source is the "standard" means of distribution
(hello Gentoo and BSD-ports users!), the much larger problem of the
transitive closure of dependencies arises. I can't readily determine how
many dependencies there are for building the entirety of apache.org's
2.2.3 but, even after subtracting LSB bits, it would number dozens at
least. For Apache to offer this in a packaged, easy to support (which is
Nick Dew's point), ready to run manner would essentially require
bundling builds of all of third-party runtime-required packages in the
build(s) that they offer. Oh, and those bundled third-party builds would
need to not conflict with any third-party builds similarly bundled by
other package authors (e.g. Samba), whether the versions were the same
or different. (N.B. Sun solved exactly this problem when it bundled
Xerces into j2se5
http://raz.cx/blog/2005/12/java-xml-and-pretty-printing.html .)

Let's not even talk about different versions of LSB.

Finally, another sting lies in the installer scripts. Debian (and I
assume others) has chosen, not entirely unreasonably, for most "related
configuration" (file diversions and alternatives, config bundles for
other packages (/etc/logrotate.d/*, ...), inetd, /etc/init.d, ...) work
to be handled by (pre|post)(inst|rm) scripts. This approach has the
great benefit that all that needs to be done can be done in whatever
form a given package requires, but also means that package portability
is a non-starter. To resolve this requires either:

- an "API" for manipulating other packages' configurations (which leads
to the very config file layout for Apache that Nick Dew objects to; the
irony is exquisite!)

or

- a declarative form for stating this stuff. e.g. For Samba it would
need to be possible to declare "IFF samba/run_mode == inetd then the
inetd service needs to listen on port 139 and
start /usr/bin/apache-from-inetd upon connection" or equivalent, noting
that Debian alone supports about a dozen inetd and inetd-equivalent
packages. Oh, and this would still create the problem that's bothering
Nick anyway.

> The next best
> approach is for them to leave it to the distros to package their stuff for
> end-users and put a warning saying that it isn't really mature enough for
> non-expert/non-developer users.

(nod)

- Raz