In article <[EMAIL PROTECTED]> 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
