libc0.3-dev is priority standard. gnumach-dev is priority optional.
libc0.3-dev Depends: on gnumach-dev, which is forbidden. One of the two
priorities needs to be adjusted, so that it no longer violates policy,
or else libc0.3-dev needs to not depend on gnumach-dev, which is
probably a bad idea.

Thanks for bringing this to our attention.  I will re-assign to
gnumach-dev.

Tks,
jeff Bailey

Hi,

Please have a look at http://bugs.debian.org/162663 for a long-pending
but easy-fixing issue (maybe you didn't get a single mail about its
reassignment).

Regards,
Samuel

only available on i386 (aka. Debian GNU/Linux on i386) and it is
imperative that gnumach be not installed by default there.

Due to current technical limitations, Priorities have to be the same
among architectures, so gnumach(-dev) is Priority: optional on hurd-i386
for the time.

Furthermore, there are related issues with Build-Essential I cannot
recite fully at the moment.  The bottom line is that we let debootstrap
install libc0.3-dev as Build-Essential, which drags in hurd-dev and
gnumach-dev due to Dependencies.  If we dropped the Depends:, we'd lose
--variant=buildd feature of debootstrap, which would be a pity and not
worth the effort.

So I think leaving things like there are for the time being (until
"arch-specific overrides" are put into place, so that packages can have
different priorities on different arches) is alright.


cheers,

Michael

PS: Thanks for all the triaging!

This bug is the only reason gnumach-dev isn't in testing:

http://bjorn.haxx.se/debian/testing.pl?package=gnumach-dev

Somebody who understands this better than me, please close this bug or
explain why it should still be open.

  Regards //Johan

Johan Walles, le Wed 30 May 2007 15:01:32 +0200, a écrit :

Mmm, I'd say the explanation given by Michael still holds?

Samuel

And I'd point that libc6-dev depends on linux-libc-dev (formerly
linux-kernel-headers) which is priority optional, and looks like exactly
the same situation. I'm wondering if this point of the policy should be
ignored for the specific case of libc-dev depending on the kernel headers,
whatever the kernel is (so the same would apply for kfreebsd).

Regis

That's right, but it's not the entire truth. We don't want those
packages on testing, that's on purpose, as hurd-i386 is not yet a
valid stable candidate. The other bug holding this would be #280987.

regards,
guillem

Guillem Jover, le Wed 30 May 2007 18:28:33 +0300, a écrit :

Mmm, but it makes sense to install the gnumach package in a stable
GNU/Linux debian system, for booting a GNU/Hurd system on the same
machine.

Samuel

This analysis is actually wrong. What is holding gnumach from entering
testing is that it has to wait 5 more days (for the 10 days criteria),
and that it has udebs, which means it's permanently frozen.

After some discussion on #hurd, once the 5 days period is over, I'll
close the mig RC bug (which is required so that it can migrate as
well, and does not produce a FTBFS for gnumach on testing), and will
request an unfreeze for gnumach so that it can enter testing.

If someone objects, please speak up!

regards,
guillem