Hi Samuel,

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
> bootstrap.

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


Reply via email to