Re: Package Pool Proposal
Philip Hands <phil@hands.com> writes:
> Sorry I'm coming late to this, I've not had much time for reading mail.
>
> Just a minor refinement idea:
>
> Put all the files generated from a source package in the same place
>
> For example, openssh would end up in a directory called something like:
>
> .../pool/o/openssh/
>
> which would contain:
>
> openssh_1.2pre10-1.diff.gz
> openssh_1.2pre10-1.dsc
> openssh_1.2pre10.orig.tar.gz
> openssh_1.2pre13-1.diff.gz
> openssh_1.2pre13-1.dsc
> openssh_1.2pre13.orig.tar.gz
> ssh-askpass-gnome_1.2pre10-1_alpha.deb
> ssh-askpass-gnome_1.2pre10-1_i386.deb
> ssh-askpass-gnome_1.2pre13-1_i386.deb
> ...
> ssh-askpass-ptk_1.2pre10-1_all.deb
> ssh-askpass-ptk_1.2pre13-1_all.deb
> ssh_1.2pre10-1_alpha.deb
> ssh_1.2pre13-1_i386.deb
> ...
>
> So that's all versions (still in use) of all the binary packages for
> all architectures produced by the source package, and all versions of
> the source package needed to produce them.
>
> This would cut down on the number of subdirectories we need to hash,
> and should make finding files by hand easier.
I think it will make finding much harder. Try to find the game called
?bink (where you don't know the first character). You would have to
look through all directories.
Theres another threat "its about the base section" that discusses a
maybe future layout of sections/interfaces/nature and other orderings
of packages, which you should probably look into.
In my eyes the most usefull odering for humans would be the nature of
a package:
server/client to server/client, libs to lib, docs to doc, development
stuff to devel and user programs to user (probably with subtypes for
games, utils,...)
I would also be anoyed to see all those sparc, hurd, m68k, i386, alpha
deb packages when looking for a source file. For that reason the
current structure of source/binary-xxx should be kept. Its far easier
for humans to find stuff on the ftp archive and frontends don't realy
care.
Another aspect is that ext2 performance goes down drastically with an
increasing number of entries and ls output with many lines is unreadable
by humans, esspecially with a ftp client that doesn't page. There
shouldn't be to many files/directories in any directory.
> Oh, and another idea --- should we try to make this so that the pool
> contains all of Debian (including non-US) where it can, and then come
> up with a way of doing partial mirrors for those places that have
> annoying laws ?
Could be. debian.org would contain everything except non-us and
non-us.debian.org would also contain non-us. All US mirrors would then
be required to mirror from debian.org (which should be the fastest
anyway) or other US mirrors. Everybody wanting non-US would have to
mirror non-us.debian.org or a mirror of that (which they already have
to do). Shouldn't be a problem for mirroring.
May the Source be with you.
Goswin
Reply to: