Re: thoughts on architectures
On Mon, Feb 11, 2002 at 01:12:28PM -0500, utsl@quic.net wrote:
> > 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.
Of course you want to standardise it as soon as you start to use it. But only
for yourself (your universe). There is no way you can devise a scheme that
fits everyone.
So, for Debian, you would want to standardise it. And for Debian, it would
be a mistake to make radical change. It would be much better to make a copy
of the existing scheme in the new interface, adn then add to it over time.
> > 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.
Which is the right thing to do because all such differences are artificial.
That is exactly the core point of my idea. As soon as I accept that there
are fundamental differences between such environmental dependencies and normal
dependencies (to stick with your naming), I have to reconsider the whole idea.
In other words, you are not consequent. Either there are differences, then you
should explain them, or there are not, and then I don't understand why you
want different fields.
> 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:
To find all possible installable packages, you have to take all dependencies
into account. This should be done by the distributor as a part of the
archive management. As you have to do this for the normal dependencies anyway
(it is done currently for normal Debian packages), the same procedures will
work if you add the arch interfaces to the normal list.
Maybe it is worthwhile to split up the checks into two (for example,
it might help error diagnostics or increase performance). I have not thought
this through. But I don't see conceptional advantages.
> > > 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
> ------------ ----
Oh that, well. I don't care about the name. Using a human readable name
has advantages, and should bbe preserved if possible. See my other mail,
too.
> 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.
Well, my arch-handling text describes a different strategy. I don't think
this should be part of dpkg or apt, and I don't think it is trivial in the
framework I think of.
Thanks,
Marcus
Reply to: