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 improved: * 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 above. Helmut
