Re: smarter way to differ architectures needed?
(Gordon will want to answer, but I want to clarify some things, too).
On Fri, Apr 02, 1999 at 11:16:39AM +1000, Brian May wrote:
> I am not sure why you would want to say that something depends on
> an architecture (ie major change involved in the way we think about
> packages) when you can do everything required the existing mechanism.
What we can't do currently is to install packages from different
architectures on one system. You need to specify "--force-architecture" to
dpkg, because dpkg does not understand that we can use (linux) i386 on the
Hurd. But we can't use all i386 packages, so we need a finer graduation.
This is where Gordons dependencies come in. Essentially, the Hurd would
provide "hurd-i386" and "i386", but as I said, not all of it. It would say
"hurd", "i386" and "glibc" for example. This way, a package which uses glibc
to operate with the system and is compiled for i386 can be used.
The "Hurd" would "provide" the functionality of the system, the packages
would "depend" on it (this does not need to be the current notion of
dependency).
A package that uses linux kernel syscalls may not work on the hurd, because
it depends on "linux", but "linux" is not provided by the Hurd. When the
heard does emulate these calls, we can provide "Linux", done.
Other example: Use of "proc" file system instead kernel calls. As soon as
the hurd has emulation, we provide "proc", and can use the i386 packages.
This *is* radically different from the current way, because we have many
more constellations and functionalities (ABI) to check. It's not just a
black and white game.
> Depends is designed to depend on other packages, it was never meant
> to indicate kernel,arch combination is required to install a package.
Yeah, but this should not distract us from the functionality here. If we
call it "Depends" or "arch-depends" or "architecture" is irrelevant. Gordon
was only demonstarting that a mechanism similar to provide+depends can be
used. This is less complex then the current mechanism, because we only need
"provide" and "depends", and hopefully not "conflicts" and "replaces".
> Using Depends line instead of architecture only complicates the matter
> of sorting packages into the Debian archive...
These two can be isolated. We can first do an architecture check, and then
disregard these "pseudo packages" for the real dependency check. We can even
put this not in the Depends: field, but in a different field, like
"Arch-Depends".
> Also: consider for instance compiling a typical binary package that will
> run on any Linux platform.
>
> Currently:
> The source package has
> Architecture: any
> This is replace when the package is compiled, eg
> Architecture: i386
>
> I can't see how your method would work. What if the resultant deb file
> will work on any i386 or if another deb file will work on any Hurd
> system (but nothing else)?
How about this:
Arch-Depends: ${cpu}, ${system}, proc
Which will be replaced accordingly. Additionally, this software makes use of
the virtual /proc file system.
> How would you specify this in the source?
> How would the dpkg packager know to automatically insert the build
> architecture into the depends line? I would rather not have the packager
> do any fooling around with the depends line, except where it is required
> (eg shared libraries).
We already use the substvars approach for this, and it seems this can be
used for those Arch-Depends, too.
> Also: remember that if a package is kernel specific, it doesn't imply
> it is arch specific, and if it is arch specific, it doesn't imply that
> it is kernel specific. In addition, some packages are arch specific in
> that they can never be expected to run on a different {kernel,arch}
> combination, wheres others just need to be recompiled for that kernel
> and/or arch. These are issues that I addressed I have addressed.
Yes, but Gordons proposal does addresse something different: Installing
packages from different archuitectures on the same machine. What Gordon is
aiming at is a much finer graduation between "needs" of the software.
> >That's not a big problem now, but it will get more and more
> >frustrating as we get more compatible (i.e. hurd-libc6 doesn't exist
> >yet, but hurd-libc0.2 still has a lot in common with linux-libc6), and
> >want to duplicate less work.
>
> Eventually, I think it should be possible for the Hurd to share the
> same glibc source package as Linux, however, somebody else will be have
> to verify this. Hence it may be a bad idea to rely on glibc6 having a
> different name on each kernel.
We already use the same source, we are just not ABI compatible right now
(that means we have to recompile later). That's why we use a different
soname (or we would be forced to use libc6.1 or sim. later like the Alpha(?)
port currently)
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@
Marcus Brinkmann GNU http://www.gnu.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Reply to: