Re: Debian GNU [was: smarter way to differ architectures needed?]
[Brian, your summary of the idea is nearly perfect. Thanks for taking
the time to explain this in a clear way that I wasn't able to. I
really depend on people such as you to interpret my grunts and
hand-waving and come up with a coherent explanation that makes sense
to other people. ;)]
To reduce confusion: the new symbol we're talking about is really just
`XOR' (exclusive OR), and the old symbol is `OR' (plain old inclusive
OR). In keeping with dpkg's convention of using the C bitwise
operators, let's make the new operator `^' instead of `||'.
I also like using `hwarch-i386' instead of `arch-i386' to make it
clear that we're describing only the bare hardware.
I've edited your quotes accordingly.
>>>>> Brian May writes:
BM> A2) Expand the depends. This involves replacing keywords like
BM> "hwarch-any" with "hwarch-i386 ^ hwarch-sparc ^ ...". How should
BM> these expansions be stored? This is an issue I have not yet
BM> discussed with Gordon, but I think for the time being it should
BM> be safe to hardcode it in a configuration file associated with
BM> the tool that does the expansion.
I completely agree.
BM> A3) Check the depends line for any "^" and replace the entire
BM> section (seperated by ',') by the value used by the current
BM> archicture. Should "|" (or) still be supported? That is an issue
BM> I have raised with Gordon.
Both have their uses, and so I agree that they should both be
supported.
BM> I think it would be simpler, at least in the short term to
BM> support both "|" and "^", but not in the one section. ie
BM> Depends: hwarch-i386 ^ hwarch-sparc, lynx | netscape
BM> would be OK and on i386 would be translated into
BM> Depends: hwarch-i386, lynx | netscape
BM> BUT:
BM> Depends: hwarch-i386 ^ hwarch-sparc | hwarch-somethingelse
BM> would be illegal as it is ambiguous. Sure, there are ways around
BM> this (ie use brackets) but I don't see any real need. Please
BM> tell me if I am wrong (give examples too).
I agree with you.
BM> Also, some names need to be given. I previously thought of using
BM> "os-any" to mean "hurd ^ linux ^ ..." but Gordon disliked
BM> it. What is a better name? "kernel-any"?
BM> "idontknowwhatthisfieldshouldbecalled-any"? ;-)
The only reason I disliked it is I couldn't think of any reason why
this field would ever be necessary.
Now, I guess it would be useful for at least glibc. In that case, the
keyword I like best is `kernel-any' -> `linux ^ hurd ^ ...'.
BM> B. Binary packages. architecture is no longer supported, but if
BM> it exists, it should be used as well as depends. ie the only
BM> change required is dpkg not to display a warning if the
BM> "architecture" field is missing (I think).
Yes.
BM> C. Packages would have to be installed to provide packages like
BM> "hwarch-i386", "linux" and "hurd". Would these need protoection
BM> against installation on incompatable architectures?
Absolutely not!
It should be possible for somebody running Debian GNU/Hurd on a Sparc
to install a binary package that `Depends: hwarch-i386, linux' if they
really wanted, given that some package on their system had the needed
`Provides'. Presumably, that package would be a kind of i386
emulator.
I know that the technology doesn't really exist now, and that there
are many complicated issues surrounding this question, but we should
at least try not to gratuitously obstruct the people who want to work
on those issues.
I think that an essential required base package should Provide the
default hwarch. Maybe that package should be `base-files'?
Kernel packages, however, provide themselves, and there should be
nothing preventing people from changing kernels without reinstalling
the whole system.
BM> D. Archive reorganisation. This is something we haven't discussed
BM> yet. I think it is going to be the worst problem (when we get to
BM> this stage). I won't even attempt to go through all the issues I
BM> can think of yet.
Fitting packages that use the new hwarch dependencies into the current
scheme is pretty easy:
1) If the binary package depends on a single `hwarch-CPU', install it
into `binary-CPU'.
2) If it has no `hwarch-*' dependencies, install it into `binary-all'.
Note that no binary package has `^' in its dependencies, because those
are all simplified by dpkg during the build process. So, the dinstall
issues are actually pretty simple.
Now, I realize that hurd-i386 is an exception to the above rules (as
would be any other kernel besides linux), but for now we can just use
the following kludge:
hwarch-all:
hwarch-any: hwarch-alpha ^ hwarch-arm ^ hwarch-i386 ^ hwarch-m68k ^ \
hwarch-sparc ^ hwarch-hurd-i386
Then, the Hurdish dpkg would choose `hwarch-hurd-i386'.
Once we deal with the remaining dinstall issues, then we can drop
`hwarch-hurd-i386', and have the Hurdish dpkg choose `hwarch-i386'
That will be a pretty major commitment from many Debian developers
(especially the archive maintainers), and so I want to defer that
issue until there is a clear course of action.
BM> [2] Implementing it as debhelper methods has the advantage if
BM> somebody doesn't like the way we have done it, they can design
BM> their own way...
I'd prefer to arrive at consensus on our design, so that we can
implement the feature once, be done with it, and move on to bigger and
better things.
--
Gordon Matzigkeit <gord@fig.org> //\ I'm a FIG (http://www.fig.org/)
Committed to freedom and diversity \// I use GNU (http://www.gnu.org/)
Reply to: