On Wed, Sep 21, 2016 at 12:26:16AM +0200, Samuel Thibault wrote:
> Sure, but dpkg is part of build-essential too, and so AIUI it thus
> needs to explain how it is supposed to build within the build-essential
I think Guillem is right here: With our current tools, it is not useful
to add such dependencies. The original error was me installing a too low
stage of hurd-dev (I built the right stage, but apparently failed to
install it, i.e. pebcak). So there are two aspects that could be
* We could gain a way to indicate that a source package does not
implicitly depend on build-essential. Then dpkg, could spell out the
subset of build-essential it actually needs. This would be very
useful for bootstrapping, but is not something we can implement
tomorrow (well, we can: Add a new header ;).
* Have hurd stop producing packages with varying interfaces. From my
pov, the real issue is that hurd stage2 produced a hurd-dev package
that doesn't mean the same thing as the real hurd-dev package. So
what I'd rather see here is to go the same route as stage1 (which
doesn't work due to #818618 yet): Rename stage2's hurd-dev to
something else, have it and the real hurd-dev provide the actual
functionality and move over the critical rdeps (mainly gcc + glibc).
Neither of these is particularly urgent from my pov, because working
around them is either done already or trivial. But implementing them,
will make bootstrapping easier in the long run.
> At the very best I'd make hurd-dev provide a libps-dev which dpkg would
> depend on, but that'd be purely artificial since we don't actually ever
> build a separate libps-dev package, the stage3 hurd-dev package already
> provides everything that build-essential is supposed to provide.
Yes, that helps for the above mentioned reason.
Thus I suggest to close this bug or turn it into wishlist bugs for the