On Mon, Nov 19, 2018 at 04:59:57PM +0100, Matthias Klumpp wrote: > Am Mo., 19. Nov. 2018 um 16:52 Uhr schrieb Dirk Eddelbuettel > <e...@debian.org>: > > > > > > Hi Ian, > > > > Thanks for the follow-up. > > > > On 19 November 2018 at 15:45, Ian Jackson wrote: > > | Dirk Eddelbuettel writes ("Our build system may be broken: /bin vs > > /usr/bin"): > > | > tl;dr: We may be messing up /bin and /usr/bin on some platforms > > | > > | This is the result of the change of the buildds to have `usrmerge', ie > > | merged /bin and /usr/bin. I think this shows that this change is > > | generating RC bugs in packages, and should be reverted. > > > > That was very much my gut feel but I am a little removed from the more core > > moving and shaking and I didn't know what changed recently. > > > > FWIW GNU R is an rather obsessively clean user of to the autotools stack, so > > I would agree that it failing here is a good-enough proof for having to > > possibly revisiting things in our stack. I would expect much more breakage > > to > > follow. > > Ideally the build system would correctly detect an usr-merged system > and set paths accordingly.
How can it do so, though, if the build system hardcodes paths to binaries[1]? Isn't it better (and easier) to have non-usr-merged buildd chroots as long as we still support such systems? [1] Yes, I know policy says you shouldn't do that, but if there's a 3000-line upstream configure.ac file that does so all over the place, fixing that might be involved, for questionable benefit (exaggerating here, but you get the point). > While reverting the change on the build > machines temporarily (e.g. until the next release is out) feels > sensible, depending on how many issues we actually encounter, at some > point we'll have to go through with it. Why? What would break if we didn't do that? [...] > I wonder how this was handled on other distributions when they made > the change - even if the change was applied on all systems, there must > have been at least one release where both modes were supported. Not necessarily. Debian is quite unique in supporting live upgrades to a new release -- for fedora, for instance, a reboot is required, and the new packages are then installed when when the whole system is offline. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard