[lsb-discuss] Packaging

[Fabian Groffen]

Apologies in advance for not having a proper In-Reply-To header, I just
subscribed to the list.  Also, I haven't thoroughly read through all
posts in the Packaging thread, so I might touch upon points already
dealt with.

Leibowitz, Michael wrote some days ago:
> 1) A unified and simple UI for installing/removing/updating packages
> that is the same regardless of distro or desktop environment
> 
> 2) Ability to detect, alert, and install updates when they are available
> 
> 3) Proper interaction with the distro, including doing the RightThing
> when the distro and package have a mutual interest in a file or service
> 
> 4) A database of installed packages, files, and assorted
> meta-information that can be queried

[snip]

> ... The other approach is what I call a secondary manager, where there
> is a manager for the third-party packages that interlinks with the
> manager for distro packages in some way.

After this follows a short discussion ending in a preference for a
"secondary package manager".  On this point I like to chime in.

For those who do not know Gentoo, it is a meta-distribution, which
basically means it does provide the "know-how" to compile and install a
package, but not the sources or binaries itself.  While Gentoo was
originally focussed on GNU/Linux on the x86 architecture, it quickly
grew into a distribution for a wide range of architectures, including
ia64, x86_64, hppa, sparc, ppc, arm, and many more.  Because of it's
"meta" nature, Gentoo's meta "tree" (a.k.a. portage tree) has been used
to compile and install packages on Mac OS X, and currently it is
extended its support to x86 and sparc based FreeBSD.  This should give
you an idea of Gentoo for those who aren't familiar with the
distribution.

Gentoo for Mac OS X always has been an outlaw in the Gentoo family.
Mainly because it had to rely on the host OS for it's toolchain and
buildtools (it installed in "/" where the OS also stored its stuff),
getting packages to work was oftentimes a daunting task and required
special hacks.  Not to mention the impossibility to "upgrade" packages
from the host OS without overwriting the originals.  Doing so could
easily render your system unusable.

Lately, we (that is a few Gentoo developers including me) have been
working on giving the Gentoo package manager, portage, support for
installing into an offset in the system.  We call this "Prefixed
Portage".  It's goals are quite similar to what I've read as wishes and
requirements, of which I quoted a bit above.  We currently use a
preliminary version of Prefixed Portage to have unprivileged users
installing the packages they like using the portage tree.  This helps
Mac OS X users on ppc and x86 architectures to install a new Vim, Perl,
Ruby, etc. but also Fedora Core 4 users to use Gentoo's GCC 4.1.1
compiler, Vim 7 ... in their own scratch space.  We had some tries with
Solaris 10, Debian and Ubuntu.

While many details have to be fleshed out, in it's preliminary stage it
is already quite effective.  A Question that I've seen in this thread
that we have too, is what to do with the primary package manager's
provided packages.  Currently we ignore everything and just build a base
system ourself during the bootstrap.  We certainly use stuff from the
host OS, but don't "provide" packages unless strictly necessary.  In FC4
for instance this includes glibc, and some other packages that cannot be
installed unprivileged, or that simply don't make sense.  I've been
toying with "yum" to list installed packages and automatically turn that
into a provided packages list that Portage can work with, but
unfortunately the versioning scheme of Fedora is different from
Gentoo's, as such it is not trivial.  However, I don't consider it
impossible to do someday.  The nice thing of "provided" packages, is
that portage will just install a newer version if required by a package.

I hope this (bit lengthy) post isn't too much off-topic, and doesn't
sound too much like a Gentoo selling trick.  (I realise it must sound
like that in some places.)  However, this is what we're working on
currently on this topic, and I am open to see where others are going.
Thanks Michael for giving me a pointer.

-- 
Fabian Groffen
Gentoo on a different level