On Sun, Nov 21, 1999 at 11:13:16PM -0800, Guy Maor wrote:
> I am going to implement something like this.
Great! :)
> 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.
You can safely do debian/dists/pool/{binary-arch,source/p/a/package, btw.
The packaging manual (section 4.2.1) guarantees at least two characters
in binary package names. I'm not sure if there's a similar guarantee for
source packages, but at the very least, none of them have less than two
characters.
FWIW, splitting on the last two characters gives you a maximum of 320 or
so collisions (ev for -dev, and oc for -doc, I guess), whereas splitting
on the first two characters gives a maximum of 617 collisions (li for lib).
[0] Just splitting on the first characters gives 732 collisions.
> A database exists that records for each package:
> - what versions are available.
> - what version (if any) are in each distribution (stable, unstable, frozen).
And experimental, presumably? How about sid and/or project/orphaned?
> - 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
Sounds good.
> 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.
(An email interface would be good too, obviously)
> 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.
This would presumably allow for things like the Gnome staging area, too?
Being able to upload a changes to gnome-staging instead of unstable might
be elegant. Being able to point Apt at project/gnome-staging might be
tidier than dists/gnome-staging. Or maybe not.
> 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.
Metalab mirrors only stable atm, fwiw. That's the one distribution which
is very easy to mirror. (Similarly, mirroring a single architecture
from a single distribution is relatively easy too, symlink binary-all
to binary-arch, and just dereference all symlinks)
> 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.)
This would just be for new packages, and not regular upgrades, right?
Would it be possible/desirable to have an experimental.debian.org machine
where this can be tested out on? With lots of disk space, but without any
sort of non-developer access; so that you can Get Stuff Done, without
having to worry about accidently trashing master or making sure you
don't accidently use more than 1.2GB (the free space in /debian atm),
or whatever? In the longer term it could be useful for testing out
alternative distributions without having to worry about using up an
extra 10GB on every Debian mirror on the planet, or similar.
Cheers,
aj
[0] for a in Packages_* Sources; do
echo -n "$a: "
grep ^Package: $a | sed 's/^Package: .*\(..\)$/\1/' | sort | uniq -c |
sort -n | tail -1
done # for the last two chars, gives:
Packages_alpha: 265 ev
Packages_arm: 118 oc
Packages_hurd-i386: 110 oc
Packages_i386: 321 ev
Packages_m68k: 282 ev
Packages_powerpc: 269 ev
Packages_sparc: 276 ev
Sources: 98 rl
Correspondingly,
for a in Packages_* Sources; do
echo -n "$a: "
grep ^Package: $a | sed 's/^Package: \(..\).*$/\1/' | sort | uniq -c |
sort -n | tail -1
done # for the first two chars, gives:
Packages_alpha: 549 li
Packages_arm: 254 li
Packages_hurd-i386: 155 li
Packages_i386: 617 li
Packages_m68k: 551 li
Packages_powerpc: 541 li
Packages_sparc: 560 li
Sources: 232 li
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
Attachment:
pgp4pfWEDV5ox.pgp
Description: PGP signature