Seperating Linux specific from Hurd specific packages
Hi,
[this proposal is not quite as worked out as I would like it to be. Partly
the reason is my lack of time, partly my sickness, and partly that the final
outcome of this depends heavily on your vision and input. I am happy to
draft more concrete proposals when the details are worked out].
there is a major problem in the seperation between Hurd and Linux packages,
that applies to a set of packages like the distribution.
The symptoms are
* packages that don't need to be rebuild for any linux
architecture, but need to be rebuild for the Hurd. Those packages can't be
Architecture: all currently, but obviously Architecture: any is overkill.
(concrete package escapes me, but think of generated scripts).
* like above, but the package is only meaningful for either platform at all
(concrete: makedev [linux all], hurd-doc [doesn't exist yet for the reason of
the problem described here], kernel-source-* [linux all] etc. Arguably, the
kernel source isn't harmful, but makedev is.
* packages that need to be recompiled on each cpu, but are only available on
one system (linux: login, and a few hundred others. hurd: hurd, gnumach, and
some more, growing). Architecture "any" isn't describing this correctly. An
exclusion list in the autobuilder can prevent the package from being built,
but the testing dist code will not know about it, and many more problems.
Even where listing all architectures is feasible, sometimes an exclusion
list might be useful, so a new dist doesn't require an addition to the list.
This bites the Hurd port badly. For example, gnupg depends on
makedev (>= SOMETHING), and although the Hurd provides "makedev", this is
not enough to satisfy the dependency. Without changing the system, we have
following work arounds available (only listed to illustrate the problem,
they are all suboptimal in several ways, or only apply to very specific
cases):
* File bugs on the packages to
+ have architecture specific control files. Semantically the right thing
in some cases, because the versioned dependency in gnupg is specific to
the linux version of MAKEDEV.
+ list all architectures in the control file rather than using any/all.
For example, makedev would have to list all linux ports, making it
necessary to recompile it. For huge packages (kernel source), this is
not feasible.
* Provide dummy packages. We do this for versioned depends on binary any
packages, which are not ported or availale on the Hurd. However, those
binaries should not be in the archive, because bug reports would go to the
real package (the name has to be the same). For binary all packages, this
doesn't work at all for obvious reasons.
(any more?)
There are many ways to attack this. Part of the problem can be solved by
supporting versioned provides. Ben told me on IRC this is hard to get
working, so you might rule it out. If we had those, it would eliminate the
need for dummy packages, but cases like makedev and kernel-source still
unpurify the archive.
The most general way to fix this is to extend the notion of the architecture
field. In addition, the Depends fields could be extended to allow
architecture specifiers just like build depends do. This would eliminate
most if not all of the cases where a control.${arch} hackery is needed
currently (in gnupg, it would achieve this, for example).[1]
So, the following are straight forward. ARCH is a Debian port name (i386,
i386-hurd, ...), SYSTEM a system type (linux, gnu [or `hurd' if you prefer).
Architecture:
any | all | ARCH [...] (as before)
all-SYSTEM (all of SYSTEM, one build)
any-SYSTEM (any of SYSTEM, one build per ARCH that belongs to SYSTEM)
I don't think I need to elaborate on this. Quite a few places would need to
be changed: apt, dpkg and dinstall would need to be able to cope with all-SYSTEM at
installation time. dpkg-genchanges and autobuilders need to be able to cope
with the whole syntax. Likely some more places.
An exclusion list (!) was suggested by Ben, it is not a requirement for the
Hurd port. If it makes it more interesting to Linux people, I am all for it.
!ARCH [!ARCH ...] (list of excluded arches, each having a ! prepended)
It would require some thought what this means (any-like, all-like?).
The suggestions above allow for some interesting extensions, like:
all-linux !m68k (all of linux, but not m68k)
Much more is possible here, but it should be thought out carefully how much
is actually useful to implement, to keep it simple to code.
Compatibility: all, any, and a list of simple ARCH names should behave
exactly as it does now, it does the right thing in the overwhelming majority
of cases.
Dependencies:
It would be useful to have architecture specifications for dependencies,
just like build dependencies have. Example for gnupg:
Depends: libc0.2 (>= 2.2.2-1), makedev (>= 2.3) [linux]
Note that we have already an extension over current build dependencies here,
a SYSTEM type name rather than an ARCH. I don't know how it happened that
build dependencies don't support it, maybe everybodys overseight. When the
Hurd gets ported to more than intel, we will face a problem here, because
currently we have:
Source: glibc
Build-Depends-Indep: texinfo
Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
hurd-dev [hurd-i386], gnumach-dev [hurd-i386]
And !hurd-i386 really means "linux" here, and hurd-i386 means "hurd".
You might disregard this feature, but let me still point out that it will
prevent the necessity to generate the control file at build time in many
cases (example: dpkg depends on sysvinit (>= 2.72), but sysvinit might
never be ported to the Hurd (we have different init)).
It will also allow more packages to be binary-all (where control file must
be the same for all arches).
I understand that global changes like this require thought, coordination and
time. That's why it is important for me to get the discussion started, so I
see what your ideas and goals are on how to attack this problem, and look
where I can help to make it happen rather sooner than later. Also, depending
on the final solution I need to start to file bug reports against packages
to create the control file at build time. The requirements for the Hurd
port are not so big, but a slightly more flexible approach might be
interesting for everyone. Suggestions are welcome.
There is absolutely no hope for a consistent Debian GNU/Hurd archive without
some fix for the above problem, so this is a real showstopper.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Reply to: