On Mon, 19 Nov 2018 at 15:02, Dirk Eddelbuettel <e...@debian.org> 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 then. 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. -- Regards, Dimitri.
