Architecture: linux-any, hurd-any
Hi,
it would be a great benefit to the Hurd port if we actually had the
architecture specifications linux-any and hurd-any. This form is chosen to
make matching easy. This kludge (and more it isn't) would allow to specify
correctly the architecture of a whole bunch of packages like console-tools,
ld.so, modutils, procps, setserial, sysklogd, update, hurd, gnumach, to just
name a couple of examples from the essential package list. A significant
number of packages belong in linux-any (eg finer points of network
administration).
Of course, we all wish for a far better, more general approach to this
issue. But the changes necessary to allow for linux-any and hurd-any are
quite small and not widespread. The most important point is probably that
dinstall requires no changes, as the two new tags are not exported. dpkg-deb
would convert them to the proper architecture name. This is the reason why I
don't suggest here the analogeous linux-all, hurd-all, which would require far
more changes. Luckily, the number of packages where this distinction is critical
is very small (makedev is my show case, for many other linux-all packages
the additional packages don't do direct harm when installed by accident).
It would probably be an appropriate work around to make the single packages
linux-any (again, makedev is the only one where I would seriously suggest
that, because its installation is downright harmful).
Beside dpkg-dev, all software has to be enhanced that evaluates the
Architecture field of the source package. This is quinn-diff and various
other autobuilder software. Anything else?
The goal is to reach a state were the Sources file more closely reflects the
actual situation. I am glad to see so many packages declaring build depends,
which is another step in the correct direction. However, I would like to tag
the packages where I have made an examination and saw that it is linux/hurd
specific, so I can forget about it, and don't have reevaluate everytime I
see it in my list. A local exclusion list of such packages, as it is used by
the buildd people, has probably been adequate in the first time of new
Debian architectures, but I think it is really time to merge the information
back into the files where it belongs: debian/control.
As an additional note, I am not talking at all about packages where hurd
support is simply missing but can be added. Those will stick out in my
autobuilder list until they are fixed. Declaring them as linux-any would
hide the lack of support.
I would like to get some feedback. Have I missed a major obstacle, which
makes this kludge infeasible? Is there a cleaner solution in the near future
available, that can be pushed instead?
Thanks,
Marcus
PS: I just had some quick ideas how to put this distintion into the build
dependencies, but this would soon get us into very muddy water.
(for example, 'Build-Depend: libc6-dev' for linux specific packages,
and 'Build-Depend: libc0.2-dev' for Hurd specific packages, assuming that
the incompatibility is reflected in the glibc header files (for example
usage of the linux kernel headers). Those thoughts play along the thoughts
about architecture "dependencies" I made elsewhere, but would only cloud the
issue in the current situation, I think, as there would be no clear cut in
the responsibilities of Build Depends and Architecture fields) anymore, but
no clean concept either.
--
`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: