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 [EMAIL PROTECTED], [EMAIL PROTECTED] PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]