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 [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
