[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#914897: debootstrap, buster: Please disabled merged /usr by default



Hello,

On Sat, Dec 01, 2018 at 11:36:45PM +0100, Didier 'OdyX' Raboud wrote:
> Le samedi, 1 décembre 2018, 19.29:59 h CET Marc Haber a écrit :
> > This might sound like a stupid question, what will happen when a package
> > built on a usrmerged System will be installed on a non-usrmerged system?
> 
> FTR, I try to always assume that no question is stupid.  Only answers can be.
> 
> My understanding is that there's no universal answer to this; for a lot of 
> packages, the answer is "nothing"; it will just work.  For some packages 
> though, if they embed executable paths such as /usr/bin/grep where only
> /bin/grep exists on the host system, this will break.

Or it could end up as /usr/local/bin/grep or as
/home/randomuser/bin/grep just as well.

This is really a generic problem of packages not being reproducible
when embedding full path found in PATH or the build system.

Even if debootstrap and usrmerge both where nuked into orbit
the problem wouldn't go away!
(This is not a problem for packages built on official buildds already.
It's a problem when built on users machines in a "dirty" environment and
then shared.)

> 
> > Will binaries move from /usr/bin to /bin? Or will binaries move from
> > /bin to /usr/bin?
> 
> A merged-/usr has a /bin → /usr/bin symlink; so a .deb package unpacking
> /bin/grep will make that binary end up in /usr/bin/grep; but the
> /bin → /usr/bin symlink ensures that you can either access /usr/bin/grep  
> directly or /bin/grep through the symlink.


The opposite can also happen as some packages fiddle with PATH (eg. by
using AC_PATH_PROGs fourth argument) and you can thus end up embedding
/bin/awk (as on usrmerged systems /bin -> /usr/bin), when a non-merged
system only has /usr/bin/awk.

> 
> An open question I think is whether dpkg should/could at one point in the 
> future always unpack binaries to /usr/bin and never in /bin no matter what the 
> package contains (+ setup a convenience symlink in /bin if /bin is a real dir 
> ?).

I don't see how this is any better than just using usrmerge.

The long term solution, once noone any longer carries the opinion that
non-merged systems needs to be supported, would be to rebuild packages
so that the binary archives doesn't ship things in /bin et.al anymore.
Then dpkg doesn't need to do anything (and dpkg-query will be all happy
again). If you think modifying packages individually for this is to
be avoided, then someone has already mentioned the idea of doing
a dh_usrmerge that would relocate a packages files before the binary
package is compressed.

Regards,
Andreas Henriksson


Reply to: