Re: Our build system may be broken: /bin vs /usr/bin
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 <edd@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
Reply to: