On Mon, Feb 11, 2002 at 11:07:18AM +0100, David Schmitt wrote: > Which would lead to the problem, that in the pool/ there would be stuff > like: > > pool/main/p/package/: > > package_Version-1_abcde.deb > package_Version-1_lsahd.deb
[...] > Essentially rendering manual download impossible. Which is indeed a problem. > This is a question to Marcus Brinkmann: > > How can one distinguish > > package_1.0-1.deb (i686,glibc,mmx) and > package_1.0-1.deb (sparc,netbsd4) > > in the pool (i.e. filesystem)? > > I know, in your doc, you don't explicitly specify an 'encoding' for this > dependency information, but people (as simpleminded as I am) would think > about some extra entry in the Depends: field, which wouldn't help much > with filesystemlayout in the mirrors as Philip Charles mentioned in > regard to partial mirrors and things as pointet out above. This is a good question. I think the best answer I have is that if you want to keep it transparent and usable by a normal user (eg allow manual download without a lot of tinkering in the packages file), then your best bet is to limit your universe to only allow very constrained overlaps between architectures. In other words, you would normally use the traditional encoding and use special encodings for special cases of overlaps. You don't even need a special case for overlap if one package for GNU/Linux works on the Hurd, for example. Of course, the package name wouldn't tell you that it runs on the Hurd, but the dependencies would. The other possibility is to build symlink trees based on the packages file. We got rid of symlink trees in Debian in favor of the packages pool, but the pool has a similar problem in that it is less transparent for users (they have to know the source name of the package). So this problem would only be hardened. These are just some examples. Please don't think I am doing a fallacy here. Although my proposal is evry broad and flexible, I don't think you should really exploit it in that property. In an actual implementation, you would carefully choose the overlaps where they are useful. An actual implementation would hard code some of the generic parts of the design and limit flexibility in favor for transparency and pragmatics. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de