Re: Package Pool Proposal
Goswin Brederlow <goswin.brederlow@student.uni-tuebingen.de> writes:
> 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).
Ah, I see. The thing is that this has already been discussed, with a
reasonable consensus being gained for a split along the lines of
[a-z],lib[a-z],x[a-z] or some such.
As you point out above, using source packages makes this problem less
serious, since we only have to deal with 2634, not 3916
subdirectories.
In other words, we're going to have to deal with the "lot's of
directories" problem anyway, and grouping files by source package name
makes things better, not worse.
> 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.
Something along these lines was already agreed in a separate thread.
...
> > > > 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.
Except by adding needlessly to the amount of typing you need to do.
Also, if I only want that source if it's more up to date than the
binary package for my architecture, then I'll be better served if both
files are in the same place.
I just go:
cd debian/pool/h/hello/
ls
and I have a complete impression of the various versions of the
files that are available for that package.
> 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).
Since most people will use apt-get here anyway, we're only talking
about catering for the sort of people that currently download things
from Incoming. Given the number of files normally in Incoming, they
seem to be able to handle large directories already.
As I mentioned in an earlier mail, splitting the directory trees by
architecture doesn't work for overlapping architectures (e.g. i386 &
hurd-i386).
Also, splitting the directories means that if you want to get a full
impression of the versions of a package that are available, you have
to hunt round a whole bunch of directories.
> > 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).
I agree with you here. I just happen to think that ``most useful to
humans'' equals ``all files related to one package, in one
directory'', when you take into account that the humans in question
are experienced users and maintainers.
Cheers, Phil.
Reply to: