Re: thoughts on architectures
On Mon, Feb 11, 2002 at 12:47:32PM +0100, Marcus Brinkmann wrote:
> 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).
Actually, I think you'd want to standardize the naming. I was just trying
to establish a concrete example. I didn't follow through well enough, though.
> > 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.
True, but that makes it difficult to distinguish between between regular
dependacies and these architecture-type dependacies in software.
> > 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?
Simple example: you want to be able to quickly find all possible packages that
would work on your system. At that point, it'd be very useful to have a file
that looks like:
Package: telnet
Env-Depends: i386, elf, gnu-libc6
Package: wdiff
Env-Depends: alpha, elf, gnu-libc6.1
It's called an index, and it's commonly used in databases to speed things. I
think we should also consider using a db3 databases rather than flat text
files, but that's a different issue...
> > 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.
The advantage is in making it easier to find things. It'd be easier to tell
the difference between packages that could be installed, if we had some
other package installed, from those that can't be installed because of
architectural dependacies.
> > 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?
Sure: apt_0.5.4_freebsd-i386.deb vs. apt_0.5.4_i386.deb
------------ ----
If you drop the Architecture concept, you have to find another way to name
the files. I'm saying why put any information into the filename? You can get
at it with dpkg, anyway, and it's in the Packages files, so why does it need
to be in the name?
I'm thinking of squid caches. Squid doesn't put any information into filenames,
it just load balances across directories, and locates files with its database.
I don't see why that wouldn't be a good solution here.
> > 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.
It'd be unnecessary. If you have the dependacies in the Packages file, you
can trivially determine which packages are available to your system in dselect
or apt. All you have to do is find dependacies that can't be satisfied without
replacing your kernel. And if you install a kernel that supports another sort
of binary, you can automatically show more available packages. My suggestion
about using new fields rather than Depends was aimed at making that faster
and easier to determine, but with a real database, rather than text files,
it'd probably be unnecessary. Indexes would solve that nicely.
Having distributions for particular architectures wouldn't be required. All
you need is stable, testing and sid. Makes dinstall's job easy. For CD sets,
you pick a kernel, and pull a list of packages that are compatible with it.
The same algorithm dselect or apt would be using.
Reply to: