Re: Package Pool Proposal

[Goswin Brederlow <goswin.brederlow@student.uni-tuebingen.de>]

Philip Hands <phil@hands.com> writes:

> Goswin Brederlow <goswin.brederlow@student.uni-tuebingen.de> writes:
> 
> > 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.
> 
> I don't know of the game called bink (does it exist?) so I presume
> you're talking about things like squake & xquake, which are produced
> by a source package called ``quake''.  Hmm...

Just an example package name. :)

> > In my eyes the most usefull odering for humans would be the nature of
> > a package:
> 
> Unfortunately, some packages don't fall into a single category.  How
> about an X11 program for editing & formatting mathematical formulas ?
> Should it be under editors, maths, x11, or maybe tex?

It woule be a user program, so the main directory would be user or
program. Below that probably text.

X11 would be the interface recorded in the control file.

tex would be on of the in/out filters that could be mentioned in the
control file.

Editing/Formating mathematical formulas would be the use, mentioned in 
the control file (maybe only mentioned in the description)

> > I would also be anoyed to see all those sparc, hurd, m68k, i386, alpha 
> > deb packages when looking for a source file.
> 
> How about:
> 
>   ls *.gz
> 
> ;-)

Depends on the ftp client/server used. You will probably download the
full listing to a file calles "*.gz" when using a DOS box.

> > 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.
> 
> Of course there are odd cases (as revealed by a quick look through
> Packages) for example, atfs is generated from the shapetools source,
> which might not be initially obvious, but I think most cases actually
> make more sense when using the source package name, and perhaps the
> few that don't would be grounds for a wishlist bug to rename the
> source package name.

Thats not what I ment. I ment to keep the source and binary
architectures apart, i.e. in seperate directories with identical
subtrees for each. Programms won´t care, but humans will know whether
they need sources or binaries for some arch, so they can look in the
right directory (if needed) and see only the files wanted.

> > 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.
> 
> I imagine that xfree86-1 is going to be about the only one that's
> going to be a problem here.  A grep for 'source: xfree86-1' in the
> main packages file reveals 39 binary packages.  Say we're talking
> about keeping 4 versions for 10 architectures, then we'll probably
> have about 1500 files in the xfree86-1 directory, which is a bit over
> the top, but it is AFAIK an extreme case.

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.

But even with a directory for every source that will be many
directories.

> 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.

May the Source be with you.
			Goswin