Re: smarter way to differ architectures needed?
I will just indicate one or two points that I disagree with in the
last posts. I have previously stated my full opinion on this mailing
list, anyone can read the archives if they want to. Please forgive
me if I make any mistakes or suggest the same solutions that somebody
has already disputed.
In article <[🔎] 86yakcv9e2.fsf@trick.fig.org> you write:
>Seriously, though... GNU/Hurd is (or at least will be) a system that
>is ABI-compatible with Linux. The glibc, gnumach and hurd packages
>will be different, but every other binary can be the same, unless they
>*want* to use special Hurd features that aren't available under Linux,
>or are too Linux-specific (like things that use /proc, which we
>haven't written emulation for yet).
I agree. I think of the Hurd as being a replacement kernel for Linux.
Technically, I realize this is wrong (GnuMach is the kernel) but I
don't care ;-)
> B> When I'm a hurd fan, I can just select debian-hurd and hit the
> B> download key (together with stabling symlincs) and I have my hurd
> B> for all my archs.
Why not just use apt?
>The latest roadblock to my goal is the dpkg notion of Architecture.
>When that is fixed, we can move on to bigger things, like getting
>better glibc-2.1 ABI compatibility.
>
> B> /debian/link-farm/debian-hurd/... (just hurd stuff below this)
> B> /debian/link-farm/arch-i386/... (all i386 and all stuff below
> B> this) /debian/link-farm/slink/... (all slink stuff below here)
>
>Okay, now I'm understanding what you mean. Just ignore my above
>comments if you agree with them... I just want to make things more
>explicit.
I personally think that we should be using symlinks less and instead
rely on programs like apt to automagically work out where each file is
kept. Please read my previous post. This isn't a big issue for me
though how we arrange the archive, but I don't think major changes
are required.
BTW: Why isn't there the word "slink" embedded in all of the above
paths? Is that a mistake?
>All that this is pointing out is that dpkg's idea of Architecture is
>too inflexible. People should only be forced to use ABI dependencies,
>not architecture strings, to name the dependencies of their binaries.
>I think then you'd find that only a small portion of Debian GNU/Linux
>actually depends on Linux.
What does ABI stand for/mean?
Also: I published a list of software that was kernel and/or architecture
specific in my previous post. Marcus found some minor mistakes. Please
let me know if there are any other errors.
>I'd also like to see Architecture become obsolete, and replaced by
>something like:
>
>Depends: arch-i386, libc6, [...]
>
>for most packages, and:
>
>Depends: arch-i386, linux-libc6, [...]
>
>or:
>
>Depends: arch-i386, hurd-libc6, [...]
>
>for most kernel-specific packages. Very few packages (only the ones
>that use syscalls directly) would need to explicitly depend on linux
>or hurd themselves, because the libc6 ABI nearly completely insulates
>a package from the kernel.
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.
Depends is designed to depend on other packages, it was never meant
to indicate kernel,arch combination is required to install a package.
Using Depends line instead of architecture only complicates the matter
of sorting packages into the Debian archive...
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 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).
My proposal:
The source package has:
Architecture: any-any
This is replaced when the package is compiled, eg
Architecture: linux-any
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.
>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.
Reply to: