Re: Proposal: incremental release process (the package pool)
On Mon, Oct 25, 1999 at 01:20:30PM +1000, Anthony Towns wrote:
>
> Stable and unstable would remain more or less exactly as they are now. There
> aren't any changes to dinstall, or how/where you upload to, etc.
You see, the package pool idea has some advantage that your proposal doesn't
provide.
One thing is creating new distributions on the fly. Using a package pool,
you can drop all link trees, and a distribution simply becomes a Packages
file (which can be transformed into a list of files for mirroring).
This has consequences that few care about currently. For example, one thing
is the absurd situation with binary-all. Currently, binary all packages are
installed in all distributions. For one, those pollute the incomplete ports
where those packages are not installable. Secondly, this ignores the new
Hurd port. In the Hurd archive, you will find the makedev package, which is
linux specific (Hurd has its own makedev in the hurd package). There are
more examples.
The different ports have enough differences to warrant a decoupling of the
ports. Currently, all ports are treated the same too much, ignoring the
differences. With probably a Debian BSD port coming along, this gets more
and more ugly.
Also, the Hurd will support Linux binaries. This means, that some binary
i386 packages will work on hurd-i386 without recompile. This can be changed
for example by replacing the architecture field with dependencies on ABI's
(linux-2.2-syscalls, glibc-2.1. Or mach-syscalls, glibc-2.2. Or simply
glibc-2.0 if they run on both etc). But the ftp tools couldn't support such
a move without heavy changes, because ftp management is currently strictly
bound to a certain Debian port.
In other words: There are considerable differences and commonities which are
not reflected by the current design. The package pool does not care about
such aspects, and simply collects binary packages. Creating the
distributions is then a different issue, post processing. When the Hurd
supports linux binaries, we could just recreate the packages file, and all
matching linux binaries were added to the Hurd port, without reuploading
etc.
Creating and changing distributions would be much easier and a lot more
flexible. Storing files and and distributions would be distinct processes.
Seperating those should make things easier in the long run.
Another example: Introducing a new science section would be trivial, because
it does not require work on the ftp archive, just changing the scripts. The
ftp hierarchy does not need to match the package presentation. Storing files
is simplified, because no symlink trees need to be created (again,
decoupling).
On the downside: Mirroring is a bit more difficult, but more flexible, if
you only want parts of the full archive. OTOH, for a transition time,
symlink trees can be easily created automatically for convenience, from the
packages file.
As Debian grows, we need to make sure that our archive concept can cope. It
does fail on several issues already. Instead patching it, we should consider
changing it drastically internally. I think the advantages in future
maintaining are worth the one time pain resulting from a change.
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNU http://www.gnu.org for public PGP Key
Marcus.Brinkmann@ruhr-uni-bochum.de, marcus@gnu.org PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ brinkmd@debian.org
Reply to: