Bug#838392: dpkg: should build-depend on hurd-dev
Control: reassign -1 hurd Control: block -1 by 818618 Helmut Grohne, on Wed 21 Sep 2016 06:09:22 +0200, wrote: > Thus I suggest to close this bug or turn it into wishlist bugs for the > above. Right. Also adding the bug dependency. I didn't remember that we still hadn't fixed that part. So we're waiting for dpkg-genchanges' 818618 :) Guillem had concerns which he raised on https://lists.debian.org/debian-devel/2016/04/msg00326.html I answered that what we actually need here is way less invasive than what Guillem raised: https://lists.debian.org/debian-devel/2016/04/msg00327.html Samuel
Processed: Re: Bug#838392: dpkg: should build-depend on hurd-dev
Processing control commands: > reassign -1 hurd Bug #838392 [dpkg] dpkg: should build-depend on hurd-dev Bug reassigned from package 'dpkg' to 'hurd'. No longer marked as found in versions dpkg/1.18.10. Ignoring request to alter fixed versions of bug #838392 to the same values previously set > block -1 by 818618 Bug #838392 [hurd] dpkg: should build-depend on hurd-dev 838392 was not blocked by any bugs. 838392 was not blocking any bugs. Added blocking bug(s) of 838392: 818618 -- 838392: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838392 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#838392: dpkg: should build-depend on hurd-dev
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
Bug#838392: dpkg: should build-depend on hurd-dev
Guillem Jover, on Wed 21 Sep 2016 00:17:05 +0200, wrote: > On Tue, 2016-09-20 at 21:26:16 +0200, Samuel Thibault wrote: > > dpkg needs to build-depend on hurd-dev because it uses and > > . It happens that libc0.3-dev depends on it, and thus hurd-dev > > gets pulled on a normal system. But when bootstrapping, libc0.3-dev does > > not depend on hurd-dev yet. So dpkg should explicitly build-depend on > > hurd-dev to be able to be compiled with the bootstrap libc build. > > As I replied to Helmut when he brought this up on IRC, I think adding > what you proposed would be (currently) wrong. hurd-dev is already > build-essential, and if we have to spell those explicitly we might as > well stop having build-essential at all. 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. > If this is causing problems when rebootstrapping, then this tells me > we might need some stages somewhere or some build profile restricted > dependencies, new virtual packages, or packages split or… 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. Samuel
Bug#838392: dpkg: should build-depend on hurd-dev
Hi! On Tue, 2016-09-20 at 21:26:16 +0200, Samuel Thibault wrote: > Package: dpkg > Version: 1.18.10 > Severity: normal > Tags: patch > User: helm...@debian.org > Usertags: rebootstrap > dpkg needs to build-depend on hurd-dev because it uses and > . It happens that libc0.3-dev depends on it, and thus hurd-dev > gets pulled on a normal system. But when bootstrapping, libc0.3-dev does > not depend on hurd-dev yet. So dpkg should explicitly build-depend on > hurd-dev to be able to be compiled with the bootstrap libc build. As I replied to Helmut when he brought this up on IRC, I think adding what you proposed would be (currently) wrong. hurd-dev is already build-essential, and if we have to spell those explicitly we might as well stop having build-essential at all. If this is causing problems when rebootstrapping, then this tells me we might need some stages somewhere or some build profile restricted dependencies, new virtual packages, or packages split or… Thanks, Guillem
Bug#838392: dpkg: should build-depend on hurd-dev
Package: dpkg Version: 1.18.10 Severity: normal Tags: patch User: helm...@debian.org Usertags: rebootstrap Hello, dpkg needs to build-depend on hurd-dev because it uses and . It happens that libc0.3-dev depends on it, and thus hurd-dev gets pulled on a normal system. But when bootstrapping, libc0.3-dev does not depend on hurd-dev yet. So dpkg should explicitly build-depend on hurd-dev to be able to be compiled with the bootstrap libc build. So could you apply the attached patch? Thanks, Samuel -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dpkg depends on: ii libbz2-1.0 1.0.6-8 ii libc62.23-5 ii liblzma5 5.1.1alpha+20120614-2.1 ii libselinux1 2.5-3 ii tar 1.29b-1 ii zlib1g 1:1.2.8.dfsg-2+b1 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 1.3~rc4 -- no debconf information -- Samuel bouhouhouh, b il m'a abandonné. Tout ca parce que je regardais plus mon emacs que lui ! s/lui/ses messages irc/ -+- #ens-mim esseulé -+- --- debian/control.original 2016-09-20 21:21:36.395188941 +0200 +++ debian/control 2016-09-20 21:21:40.795164587 +0200 @@ -14,6 +14,7 @@ gettext (>= 0.19), po4a (>= 0.41), zlib1g-dev, libbz2-dev, liblzma-dev, libselinux1-dev (>= 1.28-4) [linux-any], + hurd-dev [hurd-any], libncursesw5-dev, libio-string-perl
