Re: Bug#4378: incomplete Packages files and incomplete distributions
In article <[🔎] Pine.SOL.3.93.960902122147.14877C-100000@brando.ece.utexas.edu> you wrote:
: I don't know of a longterm solution short of
: duplicating the contrib and non-free trees into stable and unstable
: versions.
During the time when I was "master of master", I was working on a proposal for
restructuring the hierarchy... and this is the same conclusion that I came
to. Right now, the contrib and non-free trees are, by definition, "unstable"
since they aren't frozen at release time. I don't think this is very nice
for folks who are trying to run "latest stable" bits all the time.
As an aside...
Another way of looking at it that I spent some time on one weekend is that
what you really want on the FTP server is something like a versioned filesystem
effect, where you could have an "object pool" of packages with potentially
multiple revisions per package present. Each "release", and indeed the
"unstable" tree, would just be symlink trees pointing to the appropriate
revisions in the object pool. If you picked a reasonably sized amount of disk
for the object pool, you could then treat it sort of like a cache, ensuring
at all times that any object which is the target of a currently-maintained
symlink stays around, and all other versions of objects get tossed out using
an LRU strategy as new objects are uploaded. It's a very neat idea, and
solves a handful of problems, but it presents a problem for mirror sites or
users who want to get just the objects associated with a given revision. It's
not clear to me how you'd train an ftpd to know when it should return a tree
of symlinks, and when it should return a tree populated with the objects that
the tree of symlinks on the server point to. Oh well, next time I'm resting
I'll think about it some more...
: Our ftp hierarchy is already too complicated.
Flexibility often drags complexity along. I thought it would be easy to make
'contrib' and 'non-free' be directories at the same level as 'base', 'devel',
and so forth... but met some reluctance about "making it harder" for CD-ROM
folk to do the right things by having these trees exist inside a release tree.
: > An older version of gs, which is in /buzz and which would do with
: > the existing gsfonts package, cannot be installed, because dselect
: > picks only the newest version.
:
: It seems overloading the gs name is causing problems. Joost, the
: maintainer of both gs's, offered several times to rename them to gnu-gs
: and alladin-gs and let them conflict. Perhaps this needs to be done.
: Ian?
It'd be nice, in my mind, if they were 'gs-gnu' and 'gs-alladin' so they sort
together, etc...
: > and to automatically check whether all the packages
: > others depend on are really there.
:
: An automatic dependency check would be useful.
Yep. Seems like a report to the owners of packages in question indicating
issues with the dependency tree for files installed in the stable/unstable
hierarchies would be generally useful. I don't have time right now, or I'd
offer to write it. A release criteria should certainly be that all of the
dependencies specified by packages in the stable tree can be resolved by
packages in the stable tree. Our recent discussions about dependencies
crossing the boundaries between normal/contrib/non-free trees indicate that
some checking up on what's really being done is probably a good idea...
Bdale
Reply to: