Package Pool Proposal
I am going to implement something like this.
The archive will look like this:
debian/dists/pool/{binary-arch,source}/x/package
x is the first letter of the filename. Note that packages are not
organized according to section in the archive, just filename.
debian/dists/{stable,unstable,non-free}/binary-arch/Packages.gz
debian/dists/{stable,unstable,non-free}/binary-arch/pool ->
../../../pool/binary-arch
(similar for source tree)
There are neither packages nor symlinks to packages here. The index
refers to all packages through the pool symlink.
A database exists that records for each package:
- what versions are available.
- what version (if any) are in each distribution (stable, unstable, frozen).
- what the sections and priorities are.
- maintainer overrides.
- when and by whom the package was uploaded.
- changes file for the upload
- rest of package and dsc info.
- any piece of data I can think of that somebody might need
when creating a distribution
The Packages.gz and Sources.gz are built from this database alone.
The database is editable from a web-page by maintainers/ftpmasters
(not every field by everybody of course). All changes to the archive
are made through the database. The change is then reflected in the
next day's archive run.
Complicated release strategies become easy to implement. For example
for the current unstable we might choose to release only a subset of
packages and have maintainers decide if their packages are good
candidates for release.
We can have as many distributions as we like: experimental
distributions with a particular feature, proposed updates to stable,
something between stable and unstable. Packages stay in the pool as
long as any distribution refers to them. Distributions can be managed
manually by an individual, automatically by code, or something in
between.
Creating a new distribution requires writing code which answers the
question, given the available versions of this package, which one to
choose? For example, an unstable-but-no-nmus distribution could pick
the latest, maintainer-uploaded version. A mondays-suck distribution
could ignore anything uploaded on Monday. Those are silly examples,
but they demonstrate a powerful concept.
Mirroring by architecture and by freeness is still possible, but
mirroring by distribution is not possible without a specialized tool.
I think the lack of ugly symlink trees is worth it though. Mirroring
a single distribution is not that simple today; you have to be careful
about which symlinks to follow and which to not.
New packages could be automatically handled. dinstall would drop
packages into the pool and record them in the database. The ftp
maintainers periodically review them. Perhaps unstable would not
choose the new upload until the ftp maintainer reviewed it, but a new
distribution "unreviewed" would. (You'd be surprised at the schlock
people upload that gets rejected.)
There will be some transition plan of course so that mirrors are not
overly burdened.
As you can see there are some details yet to be worked out, but that's
the basic concept.
Awaiting comments,
Guy
Reply to: