Re: Package Pool Proposal
Philip Hands <phil@hands.com> writes:
> Goswin Brederlow <goswin.brederlow@student.uni-tuebingen.de> writes:
>
> > Thats with putting all deb files generated from one source into one
> > directory. I though you wanted to put all files of all sources into
> > one directory, which would be far greater 1000.
>
> I'm not sure how you got that impression.
>
> Given that misunderstanding, I suggest you reread what I wrote and
> comment again as you see fit.
>
> > But even with a directory for every source that will be many
> > directories.
>
> Don't know what you are on about here, given the total communication
> failure that seems to be in progress.
$ grep Package /var/state/apt/lists/_usr_local_debian_dists_potato_main_source_Sources | wc
2634 5268 47661
$ grep Package /var/state/apt/lists/_usr_local_debian_dists_potato_main_binary-i386_Packages | wc
3916 8314 78675
We have 2634 source packages building 3916 binary packages in main
alone. Having one directoy for each source package would be 101
directories with alphabetic sorting (in average) and for some far
more (like x).
To reduce the number of directories you could use more than the first
letter to split up further, but then you eigther have variable length
splitting (e.g. a/ b/ x11/ xf/ ... or a/ b/ x/1/1/ x/f/) or many
directories with only very few files. For the user it will not be
clear where to look for a package. He would have to know how many
files would be in the same directory along with wht he looks for and
from that decide what splitting was used.
For example a user could not just type "wget ftp://ftp.debian.org/debian/dists/potato/main/binary-i386/x11/xserver_vga16*";.
The alphabetic splitting into directories doesn´t mean anything, so no
information is gained from it. Using for example the useage of a
package would carry some meaning and make it easier for the user to
know from memory (or straight thinking) where a package would be (even
if he doesn´t know the name).
> > > Perhaps we should allow for versioned subdirectories
> > > (pool/x/xfree86-1/3.3.5-2/ say) which would keep this within
> > > reasonable bounds, but I'm not sure it's worth it for this one case.
> >
> > Don?´t think thats really neccessary. When seperating sources and archs
> > you will have 39 * 4 packages in each directory.
>
> The whole point was to not separate the sources & archs, because that
> makes things easier to find for humans,
I disagree with that. One normaly knows what architecture (or source)
one looks for, so putting that information into the path doesn´t make
it harder to find files. On the other hand, leaving that out of the
path drastically increases the number of unwanted files in a directory
(by a factor of 5).
> and makes no odds to machines.
I agree fully with that, so the most usefull for humans ordering
should be used (without causing massive traffic like the current
stable/unstable approach).
May the Source be with you.
Goswin
Reply to: