Re: Our build system may be broken: /bin vs /usr/bin
- Date: Mon, 19 Nov 2018 16:11:14 +0000
- From: Dimitri John Ledkov <xnox@xxxxxxxxxx>
- Subject: Re: Our build system may be broken: /bin vs /usr/bin
On Mon, 19 Nov 2018 at 15:02, Dirk Eddelbuettel <edd@xxxxxxxxxx> wrote:
> tl;dr: We may be messing up /bin and /usr/bin on some platforms
> Sorry for the alarming headline but #913982 was filed, indepedently
> corrobated and simultaneously discovered by upstream.
> GNU R has long been relying on sed, tar, bzip2, ... and many more base
> tools. No issues there. Generally looked for in /bin and found there.
> Starting with binary rebuild r-base_3.5.1-1+b2 however, /usr/bin/* path crept
> in while the binaries where still in the wrong place. It looked like a
> one-off so I uploaded 3.5.1-2 which built fine for me on amd64 ...but
> apparently is already borked again on i386.
> I am at bit of loss here. Any ideas?
In Ubuntu, whilst debootstrap and all install methods default to
merged-usr from Disco+ the buildd chroots used by launchpad are not
merged-usr. Given that at the moment in Ubuntu we are choosing to not
force-merge users on upgrade. Granted, Launchpad does not accept
binary-uploads, thus things like these are easier to curate. But e.g.
one can create local chroots with --no-merged-usr passed to the
debootsrap and upload those binaries. But obviously buildd chroots
need to be switchted to --no-merged-usr as well for the time being
Note this is a build-environment change, rather than target system
things. Possibly we should be encoding merged-usr in the buildinfo,
and e.g. using reproducible builds infra to do "build in
--no-merged-usr, rebuild in --merged-usr, result should be the same"
either as a one-off, or on the ongoing basis.