Re: thoughts on architectures
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 brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Reply to: