Re: thoughts on architectures
On Mon, Feb 11, 2002 at 01:25:51AM -0500, utsl@quic.net wrote:
> I think you could say that a binary's environment is made up these things:
Whatever. The exact set of virtual package names that make up the
architecture depends on your needs (I called this the universe).
Of course you have to specify this if you want to use a flexible
architecture system. But it should not be part of the design of the
architecture system (eg nothing should depend on the selection of such
interface names).
> 1. Drop the Architecture field.
> 2. Add two new multi-value fields. I'll call them Env-Provides, and
> Env-Depends. Probably someone else can think of better names.
Why do you want to replace one evil with another? The existing Provides:
and Depends: can cope with non-existing package names (called virtual
packages). Those are exactly what you need for the interfaces like the CPU
etc.
> 3. Make those fields provide and depend on tags which are completely
> separate from package names. This makes it easy to distinguish
> what packages a package depends on from the environment it's been
> built for.
I don't understand what you mean here. Can you elaborate?
> It also makes it easier to make an index of packages
> for a particular architecture combination,
Why?
> and doesn't pollute the
> package namespace with a lot of virtual packages.
Beauty is in the eye of the beholder. I think having two fields duplicated
without any real technical advantage is adding to ugliness.
> 4. Drop keeping metadata in package filenames. Make them just a unique
> string, assigned when the package is installed into the archive.
I don't understand at all what you are aiming at here.
> That gets rid of the need to add something to the filename to
> distinguish i386 from sparc packages.
Can you cite an example?
> favour of going further: use one Packages file, and determine
> available packages based on the tags your kernel and libc support.
I think you misunderstand the purpose of the packages file. The packages
file determines what is in the distribution for a specific architecture. So
dinstall (katie, whatever) would decide if a new package in the pool would
enter a packages file or not based on the dependencies in the package.
I am probably misunderstanding you, but without an idea want you want to
achieve with 4 above I have trouble to see why you would want to change
that.
> > Yes, exactly. And you need some differences in the algorithm that decides
> > when to compile a package from source for a given architecture (the pool
> > might contain a compatible but inferior binary package).
>
> But that's not a problem for the guy who makes the CD's.
No, of course not.
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: