Sorry for not replying sooner. I wanted to first do my homework and
dig through Gentoo's docs, but I'm still in the midst of their howto.
I'm also cc:ing to the list as you asked.
In particular, there are a set of global --options that Portage can pass to
the configure phase of installation. This allows you to do things like
globally specify --qt-dir, or --no-x11.
Yes, I've seen mention of the USE directive. Pretty smart.
The great thing is that the ebuild files can be really terse. For example,
unlike RPM's spec, you don't have to specify where every file lives for
installation purposes; Portage discovers this information from the chrooted
This is what Debian does, too.
File tracking. Package management. Querying which file belongs to which
package. That sort of thing. You can even have Portage build a binary
distribution from an already installed package, something I'd have expected
RPM to be able to do, but doesn't.
One of the nicest thing I've seen in their docs is the ability to
*not* remove the package before the new is installed. Of course not
every application will be so picky to absolutely need this, but it is
> > is no dependancy from the tarball to the spec, unlike .rpm, .deb,
> Conceptually there is neither, too, in debianized sources. The specs
> reside in the standard directory extracted from the tarball but could
> be kept anywhere else.
What I'm saying is that there is /no/ dependancy at all with Portage. Since
the sources don't have build rules in them (aside from their normal
configure/make/ant/whatever scripts). The sources don't know that they're
going to be installed on Portage.
In contrast, you must 'debianize' the sources to make them work with
Sorry, I wasn't clear. `Debianizing' is exactly the act of building
that `spec' directory. You could just (and in fact I've done) take
the upstream tarball, unpack it, drop the debian dir in it, and the
.deb package will be built. The binary package is built by chrooting
into a directory and running whatever installation mechanism the
upstream source had, too.
> FIX: Shift the task of the spec from installing a .tar.gz to building
> a directory structure conforming to the distribution policy, that is
> later handed to the installer and database manager.
Portage's fix is this (I said this above, but I want to be clear):
When portage runs the 'install' phase, it installs into a temp directory; EG
/var/lib/portage/<package>. So you get something like this:
Portage then indexes that directory, and just copies stuff to their
I've tried to go a step further with rpkg. Basically, the packager
decides the `meaning' of each part by putting it in a specific
directory (ext for extensions, bin for executables, and so on). The
packager does not really know where each part will go in the client's
file system. `bin' files might go in /usr/bin, in /usr/local/bin, in
/home/john/bin... the choice is left to the end user. It's ok, of
course, to go with defaults and have `bin' go into /usr/bin, `doc'
into /usr/share/doc etc., but I'd like to preserve the freedom of the
end user to change that.
On Tue, Jul 02, 2002 at 12:24:02PM -0700, Sean Russell wrote: