Re: Package organization on CDs [was Re: Packages files references packages in pool instead of binary-... location]
On Mon, 18 Dec 2000, J.A. Bezemer wrote:
>
> On Mon, 18 Dec 2000, Petr Cech wrote:
>
> > > While a pool structur is usful for directly downloding files or building
> > > distributions, it is not for the distribution itself. Especially if
> > > distributed on CD's the current binary-... structur is much better. And
> > > Packages files are an integral part of distributions.
> >
> > you're wellcome to fix debian-cd to do this. I agree that it would be nice to
> > have it on the CD as it was
>
> Thus far the .deb package organization on the CDs has reflected the situation
> in the main archive -- which was the logical choice. However now that we're
> going to have package pools, we might want to reconsider this. Currently
> section-based ordering is used, so there's for example binary-i386/admin/
> through binary-i386/x11/. But, following the pool model, there could also be
> binary-i386/a/ through binary-i386/z/, and in those directories either all
> packages starting with that letter (with "special" lib* handling) or
> subdirectories based on source package name (most of which would only contain
> one single file).
>
> Personally, I'd like the "first variant" of the name-based hashing, simply
> because more than once my first guess of the section name turns out to be
> wrong.
>
> I suppose the package organization should be as convenient as possible, and
> since no programs (should) depend on it, this would mean convenient-for-
> humans. And I think everyone actually using this directory structure knows
> what package(=filename) he/she is looking for, but not always in which section
> to classify it.
>
> I do agree that it would be desirable for all packages to be present under
> binary-$ARCH (maybe with or without binary-all and/or symlinks between them).
> But to further follow the "example" of the main archive, there could also (i.e
> as second "access point") be a pool/ directory with sym- or hardlinks to files
> under binary-*/, or the other way around. Required diskspace for hardlinks
> would probably be <1 MB, but for symlinks could get up to about 10 MB (per CD
> that is).
>
> Opinions? Other options? Strong supporters of any particular structure?
Sure. I think it would be much easier to use the 'pool' scenario. However,
for backward compatability (with humans still stuck in the mode) I think
symlinks/hardlinks would be acceptable.
Is there a way to script something into dpkg, apt, dselect, or other
package management software to allow a file to represent virtual symlinks
on the CD? I mean, have the package redirection information downloaded
from the ftp site, and put into a file, and then mount the file, when the
CD-Install is initiated, to allow the file to be access for symlinking?
I think that qualifies as a run on. :) I've been at work too long. Hope
that made sense.
-John
phenom@wwti.com
Reply to: