https://lwn.net/SubscriberLink/890219/79e54e3aab20bd87/

LWN.net Logo LWN
.net News from the source LWN

  * Content
      + Weekly Edition
      + Archives
      + Search
      + Kernel
      + Security
      + Distributions
      + Events calendar
      + Unread comments
      + -------------------------------------------------------------
      + LWN FAQ
      + Write for us

User: [        ] Password: [        ] [Log in]
|
[Subscribe]
|
[Register]
Subscribe / Log in / New account

Debian still having trouble with merged /usr

[LWN subscriber-only content]

    Welcome to LWN.net

    The following subscription-only content has been made available
    to you by an LWN subscriber. Thousands of subscribers depend on
    LWN for the best news from the Linux and free software
    communities. If you enjoy this article, please consider
    subscribing to LWN. Thank you for visiting LWN.net!

By Jake Edge
April 5, 2022

The addition of the "/usr merge" feature has been something of
longstanding mess in the Debian world. It seems like a relatively
innocuous change, which is in keeping with the practice of most other
distributions at this point; it effectively eliminates the top-level
/bin, /sbin, and /lib* directories in order to move their contents to
the corresponding locations under /usr. But ever since we first
covered the feature introduction for Debian--more than six years
ago--it has a been a recurring series of headaches within that
community. Recent events have seemingly simply prolonged the pain,
though perhaps the end is in sight.

Background

The /usr merge idea was first raised in "The Case for the /usr Merge"
by Lennart Poettering in 2012. It came out of the systemd community,
but was not meant to be systemd-specific, though, as the comment
thread on that LWN post indicates, the idea was controversial at
least in part because of its association with systemd. At its core,
it was a straightforward plan to move the files in /bin to /usr/bin,
then make a symbolic link so that /bin would resolve to /usr/bin; the
same would be done for the other top-level directories of interest (/
sbin and /lib*).

The main reason behind the merge was for compatibility with other
Unix systems and to make building packages for Linux distributions
easier; upstream software, build tools, and the like would no longer
have to treat Linux specially. Anything that relied on /bin/foo or /
usr/bin/foo would find what they were looking for, but everything
would live under /usr. That would permit things like an immutable,
distribution-supplied /usr, snapshots of the system state would be
simpler, and so on.

Fedora, as is often the case, took the lead and implemented merged /
usr, for Fedora 17 in 2012. Other distributions followed suit, with
most of the mainstream distributions following the Fedora approach of
having a "flag day" switch; new or upgraded versions of the
distribution would either install a merged /usr or switch the system
to use that as part of an upgrade. Supporting both the old and the
new layout simultaneously was not something those distributions chose
to do.

Debian took a more incremental approach, in part because it strives
not to make wholesale changes to users' systems like those required
by a flag-day upgrade to a merged /usr. In 2016, the ability to
voluntarily switch to that scheme was added, then some attempts were
made for newer versions of the distribution to be installed with a
merged /usr by default. In 2018, the Debian build systems were
switched to use that layout, but problems cropped up because packages
built under a merged /usr would sometimes fail to work on non-merged
systems. The location of some files was being resolved at build time
to point into /usr/bin (for example), but those files only existed in
/bin on the non-merged systems.

The build system changes were reverted, so that both types of systems
could be supported. But the problem led Ian Jackson to ask the Debian
technical committee (often abbreviated as CTTE or ctte), which is the
ultimate arbiter of technical disputes within the project, to
override the decision by the debootstrap developers to make merged /
usr be the default. Debootstrap is used to create a base system into
a directory that can then be used as a chroot environment for
building additional packages, though it has other uses as well.

The committee declined to overrule the debootstrap maintainers, but
did give a lengthy summary of the cases for and against /usr merge.
The committee also used its advisory role to note that the
then-under-development Debian 10 ("buster") would support both system
types in a "weak" form, but suggested that it was desirable that
Debian 11 ("bullseye") move toward a "middle" ground with better
support for merged /usr.

Debian, being Debian, discussed the issue multiple times along the
way, at varying levels of intensity and rancor. Supporting both types
of systems was difficult in various ways, leading some to say that
either /usr merge should be made mandatory--or scrapped entirely. At
the end of 2020, Ansgar Burchardt asked the technical committee to
decide whether Debian 12 ("bookworm") should only support merged /usr
systems. At the end of January 2021, the question was put to a vote,
and the result was unanimous in favor of doing so:

    The Technical Committee resolves that Debian 'bookworm' should
    support only the merged-usr root filesystem layout, dropping
    support for the non-merged-usr layout.

    Until after the release of 'bullseye', any implementation of this
    resolution must be done in the 'experimental' distribution, or
    otherwise kept out of the critical paths for the release of
    'bullseye'.

Symlink farms

That would seem to resolve the situation, in favor of a flag day for
Debian 12, but, as might be guessed, things did not quite work out
that way. During the discussion on the vote, committee member Simon
McVittie expressed concern that there were two competing visions of
what a merged /usr meant. He wondered: "Should we be more specific
than this in what we vote on, to avoid later having to adjudicate
between developers who say that a particular implementation is or
isn't merged-usr?" That comment would foreshadow the events to come.

The "standard" way to support /usr merge, as described above, is
sometimes called "merged /usr via aliased directories". It is what
the usrmerge tool, which got the ball rolling for Debian in 2016,
does; that mechanism is tracked on the UsrMerge page on the Debian
wiki. An alternative, which is championed by dpkg maintainer Guillem
Jover, uses "symlink farms", which McVittie described as follows:

    an arrangement where all regular files that have traditionally
    been in /bin, /sbin, /lib and /lib64 are physically located in /
    usr, with /bin etc. becoming "symlink farms" containing symlinks
    like /bin/sh -> /usr/bin/sh, /lib/ld-linux.so.2 -> /usr/lib/
    ld-linux.so.2 and so on

There was some discussion in the bug entry about the advantages of
the two different arrangements, but most of the participants seemed
to think that the symlink-farm approach was not desirable, viable, or
both. Along the way, McVittie realized that the earlier decision on
debootstrap seemed to indicate that the committee thought that the
aliased-directories mechanism was the singular approach to solving
the /usr merge problem. His vote reflected that understanding.

The discussion moved to the mailing lists, where a certain amount of
consensus was found, at least in some areas. McVittie opened a bug
asking the committee to resolve the aliased directories versus
symlink farm question along with others swirling around the upcoming
/usr merge transition for bookworm. He was asking the committee to
use its formal advisory role to offer guidance on how that transition
should proceed.

A lengthy statement was put out for a vote by the committee; once
again, it passed unanimously. The advice clearly rejected the
symlink-farm approach, in favor of aliased directories, and made it
clear that packages could not assume that systems have a merged /usr
until Debian 13 ("trixie") development starts. Beyond that, the
committee advised that upgrading from either type of system to
Debian 12 should work, packages should build and function on both
types of systems (until after Debian 12), and a few other items. The
bug was marked as "done" on October 18 and, once again, it seemed
that the situation was resolved.

Dpkg resistance

Meanwhile, though, the dpkg maintainer was adamantly opposed to the
aliased-directories approach; his complaints were described in a
MergedUsr page in the dpkg team's section of the wiki. It presented a
long list of problems with that approach because the mechanism is
handled outside of dpkg itself:

    This approach goes behind dpkg's back, and has caused and [does]
    now cause problems due to the aliased directories, as multiple
    pathnames canonicalize into different pathnames that point to the
    same dentry, which can mess up anything that handles pathnames in
    databases and similar. Note: dpkg has supported for a long time
    symlinked directories as a way to allow local admins to manage
    filesystem size constraints, by moving directories contents into
    other partitions, but has never supported aliased directories via
    symlinks pointing to other directories already tracked by dpkg.
    This approach makes it impossible to know what is the canonical
    (from dpkg's PoV) pathname for an object just by looking at the
    filesystem, so it is trivial for users use the wrong one.

Many of the entries in the list were marked with a symbol indicating:
"This approach is considered broken by design and is unsupported by
dpkg. dpkg-buildinfo marks packages built on these systems as tainted
in the .buildinfo file." The symlink-farm approach is superior, the
page says, even though it still has the aliasing problem for the
symbolic links that get installed:

    This still suffers mild aliasing problems, but only for pathnames
    that will end up in both locations due to backwards compatibility
    symlinks, which should keep decreasing, and any such issue will
    self-heal over time, eventually ending up being just a handful of
    them. The big difference is that in the long term this is a tiny
    and decreasing bounded set of pathnames that might end up causing
    problems, while the other layout is an unbounded set affecting
    all pathnames permanently. Another thing that makes a difference
    is that the object is a symlink, and not the same object being
    accessed from different pathnames.

Both that page and the dpkg FAQ entry recommend using the
dpkg-fsys-usrunmess utility, which "undoes the merged-/
usr-via-aliased-dirs mess". So it was perhaps unsurprising when Josh
Triplett reported in mid-March that dpkg had started to emit a
warning when it was installed or upgraded:

    Setting up dpkg (1.21.2) ...
    dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs.
    dpkg: warning: See <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>.

    This escalation seems in direct contradiction to the tech-ctte
    decision in 994388. Moreover, this seems to effectively use
    package maintainer scripts as a means of directing a complaint at
    Debian users that has not gotten traction in other forums, and
    then directing such users at a wiki page that contradicts a prior
    project decision.

His report was aimed at the committee bug that resulted in the
decision back in October. As Russ Allbery noted, that kind of a
warning "will be perceived by users as an official declaration from
Debian as a project that their system configuration is unsupported,
while simultaneously this is the default installation mode for new
systems and something that we have elsewhere said is a correct system
configuration". Burchardt said that the warning was already causing
confusion and asked the committee to decide quickly on how to handle
it "to avoid this becoming yet another energy drain (we had several
sufficiently long enough threads about this topic already)".

Bugs and fixes

There is a question of what "supported" means in the context of /usr
merge, Helmut Grohne said; he was added to the committee at the
beginning of the year after two members reached their term limit and
retired from it. He said:

    At this point, neither merged-/usr nor unmerged-/usr is supported
    well. Both are broken in one way or another and nobody steps up
    to fix the mess. In particular, the dpkg maintainer does not
    support merged-/usr in dpkg (which is his constitutional right as
    long as he does not block reasonable patches), but neither does
    anyone else. As such I find it difficult to disagree with the
    content of the warning. I do see how it confuses people. It
    definitely does not reach people who could do something about
    [it]. Rather it takes users as hostages.

As had been mentioned in some of the (many) threads surrounding this
issue, Ubuntu has successfully made the move to a merged /usr; as
Luca Boccassi put it: "And on top of new installations, old
installations of Ubuntu upgrading to 21.10 and/or the
soon-to-be-released 22.04 have been [forcefully] migrated too. They
are not blocked, unsupported, or broken." There have been few
problems with that transition, at least according to /usr merge
proponents, so whatever bugs exist are not show-stopping. But Allbery
cautioned against taking that too far:

    We know that merged-/usr is buggy, in that one can construct a
    set of package operations that leave the system in an invalid
    state. We have a project disagreement over how serious those bugs
    are. No one is stepping forward to fix those bugs, which is
    indeed quite unfortunate. I personally strongly disagree with the
    belief that simply because Ubuntu hasn't seen many instances of
    this class of bugs while using a package set where people have
    not moved files between packages and out of /lib and /bin very
    much if at all, it is acceptable to leave dpkg in that buggy
    state.

    [...] I personally am disappointed that the folks who have been
    pushing merged-/usr forward are willing to leave dpkg in a
    known-buggy state without attempting to patch it to fix the
    remaining issues. I realize that there are various obstacles in
    successfully doing that, not all of which are technical, but I
    want to believe that Debian is the sort of project that will do
    the hard work (both technical and social) to fix edge cases and
    maintain a high level of consistency and correctness.

But Triplett disagreed with that characterization:

    It does not seem at all obvious that such patches would have been
    accepted, given the repeated vehement objections from the dpkg
    maintainer about the chosen approach. Those objections did not
    invite contribution; at every point, the assertion was that
    usrmerge was broken, not that dpkg needed help supporting it.

Boccassi said that looking at Ubuntu's experience is legitimate; the
problems identified are relatively small and "it's believed to be
impossible to get them fixed" over the maintainer's objections. He
asked what else would be a reasonable way forward. Allbery replied
that proponents of the change should create a patch to fix the
problems that have been identified in dpkg even though it might be
rejected. In part, it comes down to finding something that is
actionable under the powers of the technical committee, he said in a
follow-up: "It's difficult, procedurally, for the TC to do anything
about a theoretical patch that someone could write but hasn't
written."

Committee chair Sean Whitton agreed with that analysis, though he did
say that he thought the committee could take action to get the
warning changed or removed; other members concurred with that view.
Shortly thereafter, Triplett pointed out that the warning message had
changed, though it was not really any better in his view.

Grohne also wanted to see fixes for dpkg to better support merged /
usr. He even mentioned the possibility of reverting the change:

    If the resulting bugs do not get fixed, we may need to consider
    other means for limiting their impact. The most obvious method
    here is revisiting the decision and considering whether the /
    usr-merge may have failed. On a process level, it certainly has
    failed. At some point, we may need to look at a bigger picture
    than the technical one. If the people driving the change are not
    able to do it, then maybe we should not have that change in the
    first place and revert back to the known working state. Of course
    that route is not without cost.

A patch arrives

But as the thread progressed, Boccassi noted that a link to a dpkg
patch had just been posted to IRC by a user named "uau". Allbery
(among others) was elated to see the patch and immediately had some
feedback on ways to improve it. Committee member Gunnar Wolf thought
that the "patch seems sane from a first, very much
10000m-point-of-view"; he wondered if it had "been shared with
Guillem, or included in any relevant bug report".

Boccassi followed up with some more information from the author of
the patch, again from IRC. The author said "that some time ago the
patch was presented to the dpkg maintainer, who rejected it with an
answer along the lines of the usual 'usrmerge is broken by design',
with no further comment". Boccassi wondered if those who had been
looking for a patch of this nature would "try and take it forward
themselves". Based on that conversation with the author, the license
of the patch is the same as for dpkg, so that should not be a
barrier.

Grohne said that he remembered some more concrete criticism of the
patch and that the patch itself says that it is incomplete, so it
cannot go into dpkg in its current form. He lamented the state of the
transition, and once again raised the specter of reverting the whole
thing:

    The more and more I have to deal with the /usr-merge the more I
    get disappointed by how badly this transition is planned and
    carried out. In principle, the technical merits seem solvable to
    me, but the total failure on the process level leaves me wish for
    a revert. I am really surprised that instead of improving the
    process, you carry on with that destructive attitude. Given this,
    it seems unsurprising that Guillem does not want to interact with
    you. Of course that's not an excuse for implementing the recent
    changes to dpkg. The communication is clearly failing on both
    sides, which is why we're here at the ctte again.

Burchardt asked that Grohne stop suggesting a revert unless he wanted
to start the process of asking the committee (or the developers by
way of a general resolution) to do so. There are lots of problems
with making that change at this point, so: "If you don't want that
solution, please don't suggest it repeatedly: it's non-motivating to
spend any further time."

Things went further off the rails on March 29, with a non-maintainer
upload (NMU) for dpkg made by Bastian Blank that removed the warning
and stopped installing dpkg-fsys-usrunmess. An NMU is something of a
hostile act for a package with an active maintainer. As reported by
Triplett, the NMU was quickly overridden by Jover with a comment: "
This also clears a bullying NMU." As Triplett put it: "we're now even
further into full-blown 'fights in the archive' territory".

In his most recent message (as of this writing), Grohne said that
Boccassi was not being constructive and that he was not surprised
Jover did not want to communicate with him about the problems. He
reiterated some of the problems that have occurred with the feature,
noting that the current problem was largely not technical:

    It has a history of its proponents not fixing the resulting bugs,
    but deferring them to others and/or denying/downgrading them.
    I've definitely spent more than a week on fixing /usr-merge
    breakage excluding the time discussing it. It is not working fine
    at all. Possibly, it is fixable on a technical level, but it is
    totally broken socially. Please stop this unconstructive
    behaviour.

    While this may sound single-sided, Guillem's behaviour wrt /
    usr-merge cannot be described as constructive either. Rest
    assured, that side of the picture is not being ignored. That
    should also be evident from dpkg.git at this time.

The dpkg Git repository does show a recent change by Jover that
removes the offending warning, but only on Debian systems. The commit
message could certainly be interpreted as non-constructive, as well,
however. For example: "On Debian some people seem so offended by a
(factual) warning, that the obvious recourse has been for them to
bully and abuse." The communication between proponents of /usr merge
and the maintainer of the critical package-manager for the
distribution seems utterly broken at this point--probably
irretrievably so.

It is not clear where things go from here. The technical committee
has repeatedly made its feelings known on the path it wants to see
the project take, but it cannot order anyone to do anything, exactly.
Debian developers are volunteers and its packages are the personal
fiefdoms of their maintainers. The Debian Constitution does allow the
committee to override developer decisions--to not accept a patch, for
example--but someone has to voluntarily do the work to bring the
late-breaking dpkg patch up to snuff.

It seems like some project elder (in terms of experience, not
necessarily age) could steer this kind of change through the rocks.
While it would appear to be vanishingly unlikely that the committee
would backtrack on its three earlier decisions, even though there are
two new members since they were made, it is not impossible, at least
in theory. The bugs that exist in dpkg with the aliased-directories
version of /usr merge may simply live on as irritations for a time,
since they do not really seem to rise to the level of a
release-blocking bug, at least so far. We will all have to wait and
see how it turns out in the next episode of "As the Debian Turns" ...


[Send a free link]


-----------------------------------------
(Log in to post comments)

Debian still having trouble with merged /usr

Posted Apr 6, 2022 0:01 UTC (Wed) by NYKevin (subscriber, #129325) [
Link]

How much work would it be to transform all packages in the Debian
repository, such that they only try to install into /usr and never
into /bin (or other non-/usr directories)? That *sounds* like the
sort of thing that could be automated, and you could certainly have
tests for it (e.g. make a container/VM with special poisoned /bin, /
sbin, etc., such that if dpkg tries to modify those directories
during package installation, the process is unceremoniously killed
and the test is marked a failure).

If you applied such a transformation, and kept new bad packages out
of the repository with rigorous testing, would there still be
problems?
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 0:09 UTC (Wed) by bluca (subscriber, #118303) [
Link]

Among many other issues, external repositories exist and are popular,
and likely can't be changed like that, and so do less savoury things,
from language-specific package managers to "curl install.sh | sudo
bash". This is why every successful move to merged-usr has happened
by making the top-level directories symlinks, so that it doesn't
matter what you throw at the filesystem, things just work. Anything
else really isn't merged-usr, it's something else (that most likely
doesn't work, as history shows).
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 0:17 UTC (Wed) by NYKevin (subscriber, #129325) [
Link]

Personally, I would be totally fine with curl | bash nonsense failing
with an obscure (and currently hypothetical) "dpkg: Tried to write to
poisoned directory /bin" error or something along those lines, but
then I don't think too highly of curl | bash in the first place.
Perhaps they could instead have dpkg forcibly convert /bin into /usr/
bin (and so on) whenever it writes a new key into its database (so
when your installation script tells dpkg "please install this file"
it knows where the file is really going to live), but I imagine that
sysadmins would want something like that to be configurable.
[Reply to this comment]
curl | bash

Posted Apr 6, 2022 3:07 UTC (Wed) by jreiser (subscriber, #11027) [
Link]

curl | bash is a security nightmare. It should be prohibited. At
least keep a record of what came across the network: curl > foo.sh;
chmod a-w foo.sh; sh foo.sh
[Reply to this comment]
curl | bash

Posted Apr 6, 2022 5:03 UTC (Wed) by milesrout (subscriber, #126894)
[Link]

Isn't that a TOCTOU issue? Malicious process could write the file
betweem curl and chmod. Perhaps what you really want is umask 077
before the file is created?
[Reply to this comment]
curl | bash

Posted Apr 6, 2022 5:59 UTC (Wed) by Wol (subscriber, #4433) [Link]

Couldn't you fix it with tee, rather than >

That way you are keeping a copy of what is fed to bash, although it
still doesn't stop someone modifying the file copy.

Cheers,
Wol
[Reply to this comment]
curl | bash

Posted Apr 6, 2022 6:16 UTC (Wed) by NYKevin (subscriber, #129325) [
Link]

If malicious software is running as you, with write access to your
files, then it's already most of the way to the other side of the
airtight hatchway, and you're effectively already lost (e.g. it could
ptrace your shell, and next time you run sudo, it can rewrite the
command that's passed to execve). The whole point of curl | bash is
to run software that isn't already on your system. Just curling it to
a local file will not, by itself, cause anything to run (yet).
[Reply to this comment]
curl | bash

Posted Apr 6, 2022 8:16 UTC (Wed) by wtarreau (subscriber, #51152) [
Link]

It's not just about malicious stuff it's also about blindly trusting
any assumption the script writer made about your system without
having the opportunity to review them, and more importantly running
the risk of executing an incomplete script if the transfer gets
interrupted. For example if your install script ends with "rm -rf
$HOME/.foobar" but the connection is cut after the "$HOME", "$HOME/"
or "$HOME/." and curl stops after having printed what it received,
you'll have a funny afternoon. And please don't tell me "bash will
not do it since the line is not complete", it *will* do exactly what
you wouldn't like it to do. Note that it also works with truncated
variable names like "rm -rf $HOMEDIR", "rm -rf /tmp/foobar" and
plenty of variants.

Nobody should ever use "curl|bash", that's irresponsible, there's no
valid reason except laziness for using it. At least do "curl>foo &&
less foo" and only then "bash foo".
It's not difficult at all and offers more guarantees of correctness.

[Reply to this comment]
curl | bash

Posted Apr 6, 2022 10:08 UTC (Wed) by Cyberax ( supporter , #52523)
[Link]

> For example if your install script ends with "rm -rf $HOME/.foobar"
but the connection is cut after the "$HOME", "$HOME/" or "$HOME/."
and curl stops after having printed what it received, you'll have a
funny afternoon.

If curl stops at this location, bash won't run that line because it
won't receive a newline and will instead be SIGPIPE-d.
[Reply to this comment]
curl | bash

Posted Apr 6, 2022 14:22 UTC (Wed) by wtarreau (subscriber, #51152) [
Link]

> If curl stops at this location, bash won't run that line because it
won't receive a newline and will instead be SIGPIPE-d.

No, SIGPIPE is for the writer, not the reader, so it would be for
curl that would receive it if bash had quit. Here bash receives a
regular EOF, and as you can trivially test below, it *does* execute a
truncated command that doesn't contain an LF:

$ echo -n 'echo blah' | bash
blah

[Reply to this comment]
curl | bash

Posted Apr 6, 2022 13:07 UTC (Wed) by mgedmin (subscriber, #34497) [
Link]

This is fixable by the author of the shell script structuring it so
all the work is done in functions, so the overall script is just a
bunch of function definitions followed by a call to main on the last
line.

Of course you have to trust that the author of the script you're
piping to bash is competent and not malicious.

But then again a Debian package's postinst script is a shell script
that runs as root, so you also have to trust the author to be
competent and not malicious.

[Reply to this comment]
curl | bash

Posted Apr 6, 2022 13:34 UTC (Wed) by LtWorf (subscriber, #124958) [
Link]

But stuff on debian is signed, and perhaps people are less likely to
upload malware under their real name.
[Reply to this comment]
curl | bash

Posted Apr 6, 2022 14:26 UTC (Wed) by wtarreau (subscriber, #51152) [
Link]

> But then again a Debian package's postinst script is a shell script
that runs as root, so you also have to trust the author to be
competent and not malicious.

That's precisely my point. Poeple seem to think about "curl|bash"
being secure because "it comes from a trusted site" or whatever, but
it has nothing to do with trusting the origin for not being
malicious, but for the shell doing the right thing. And we all do
bugs all the time without being malicious, and in addition the way
this is handled cannot protect against transport issues.

The only way to make this reliable is to first download, then execute
if the download completed successfully (and you've done the necessary
extra checks that depend on the origin and your level of trust).
[Reply to this comment]
A program to securely replace `curl | bash`

Posted Apr 6, 2022 15:31 UTC (Wed) by KJ7RRV (subscriber, #153595) [
Link]

Would it be useful to have a program that would download a script,
show it with a pager, and execute it with a shell? It could stay in
memory the whole time, so unless an attacker can modify the process's
memory they shouldn't be able to hijack the process (and if they can
modify the memory of other processes, trying to protect against them
likely won't do much good[?]). netrun https://example.com/
a-shell-script.sh netrun --interpreter=python3 https://example.com/
a-python-script.py
[Reply to this comment]
A program to securely replace `curl | bash`

Posted Apr 6, 2022 15:33 UTC (Wed) by KJ7RRV (subscriber, #153595) [
Link]

Oops, the commands didn't format correctly.

netrun https://example.com/a-shell-script.sh

netrun --interpreter=python3 https://example.com/a-python-script.py

[Reply to this comment]
A program to securely replace `curl | bash`

Posted Apr 6, 2022 16:55 UTC (Wed) by wtarreau (subscriber, #51152) [
Link]

Maybe. For sure most users wouldn't care, but it could at least
excite their curiosity and encourage the authors to be even more
rigorous. This could also highlight the insane UTF-8 homoglyphs and
RTL hacks.

[Reply to this comment]
A program to securely replace `curl | bash`

Posted Apr 6, 2022 19:33 UTC (Wed) by KJ7RRV (subscriber, #153595) [
Link]

Yes, that would be a good idea! It could possibly even run a simple
malware scan to check for things like fork bombs, although it
wouldn't be perfect.
[Reply to this comment]
curl | bash

Posted Apr 6, 2022 19:50 UTC (Wed) by gnu_lorien (subscriber, #44036)
[Link]

"Nobody should ever use "curl|bash", that's irresponsible, there's no
valid reason except laziness for using it. At least do "curl>foo &&
less foo" and only then "bash foo".
It's not difficult at all and offers more guarantees of correctness."

The valid reason is that people don't know how to make this safer and
there's often no way to install the software they need other than
doing this.

This is one of those areas where I think distros and package
management software have really failed their users. If "It's not
difficult at all and offers more guarantees of correctness" then why
don't we have things like:

dpkg -i --web-bash-url=http://site-you-can-trust.org/install.bash
dnf -i --web-bash-url=http://site-you-can-trust.org/install.bash

One can envision how these systems could do something to keep a
history of what those scripts did and what they changed that would be
extremely difficult for users to put together on their own in a
one-liner. Why don't they?

I could make a similar argument for package systems and their disdain
for vendoring. Like it or not this is how a lot of packages are
shipped to consumers and users are not choosing the distros over the
software that they want. After all the hemming and hawing about how
"npm should do better" all users really come away with is, "My
distribution can't install the software I want, so I'll use whatever
the website suggests."
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 3:25 UTC (Wed) by foom (subscriber, #14868) [Link]

> Perhaps they could instead have dpkg forcibly convert /bin into /
usr/bin (and so on) whenever it writes a new key into its database
(so when your installation script tells dpkg "please install this
file" it knows where the file is really going to live),

Indeed this seems like an obvious answer. And, it is effectively what
the proposed (but reportedly summarily rejected) dpkg patch by "uau"
implements. Only instead of normalizing on database write, it
normalizes on database read.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 0:45 UTC (Wed) by atnot (subscriber, #124910) [
Link]

There is a great summary of why Debian is unable to efficiently make
large scale changes like these in this blog post: https://
michael.stapelberg.ch/posts/2019-03-10-debian-win...
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 13:09 UTC (Wed) by mgedmin (subscriber, #34497) [
Link]

It's one of the reasons why Ubuntu exists: Debian development is like
herding cats and makes it hard to make sweeping distro-wide changes.
IIRC this was mentioned at least once in a talk by Mark Shuttleworth
as a reason why he decided to found Ubuntu instead of running for
DPL.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 2:29 UTC (Wed) by josh (subscriber, #17465) [Link]

Long-term, that's not a *bad* step, but it's not sufficient given
third-party packages and repositories.

What we could do, though, is give dpkg a list of directory mappings,
and have it automatically translate all files from packaged location
to installed location at unpack time as though the package shipped
them in those locations.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 1:00 UTC (Wed) by milesrout (subscriber, #126894)
[Link]

There is a simple solution: do not do the merge. The merge is
incorrect behaviour. We have PATH. Use it. If we were to merge
anything it should be to the far more sensible /bin as the standard
path.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 1:02 UTC (Wed) by KJ7RRV (subscriber, #153595) [
Link]

Yeah, I've also wondered why the move is from / to /use/ and not vice
versa.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 1:04 UTC (Wed) by KJ7RRV (subscriber, #153595) [
Link]

:%s/use/usr/g

:%s/autocorrect/autoincorrect/g
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 15:29 UTC (Wed) by Wol (subscriber, #4433) [Link]

c/autoincorrect/autocorrupt/

Cheers,
Wol

[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 2:06 UTC (Wed) by josh (subscriber, #17465) [Link]

Multiple reasons.

First, technical challenges: HURD tried to move from /usr to / and
had quite a bit more trouble with it, and that trouble warned against
trying it on a larger scale. It's much easier to move from / to /usr
than from /usr to / ; fewer things break.

Second, consolidation: moving *into* /usr gives us a single directory
containing all files managed by the distro / package manager. This
has quite a few advantages. It makes sharing /usr among several
chroots or containers feasible (one /usr, different /etc and /var).
It makes versioning and A/B upgrades (upgrade to new image, fall back
to old image if new image doesn't boot) simpler and easier. It makes
it easy to lock down /usr with something like fs-verity.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 15:33 UTC (Wed) by juliank (subscriber, #45896) [
Link]

Second argument doesn't really hold at the moment, as /etc and /var
are managed by the package manager too.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 16:00 UTC (Wed) by bluca (subscriber, #118303) [
Link]

It can actually work, and it's getting better all the time as more
and more software is updated to avoid a hard-reliance on a
pre-populated /etc. Fresh from the press: https://0pointer.net/blog/
running-an-container-off-the-ho...
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 1:59 UTC (Wed) by calumapplepie (subscriber, #
143655) [Link]

#!/usr/bin/ohwaitthisdidntgothroughpath

Quick: is bash in /bin or /usr/bin? How about python? awk? groff?
pearl? java? (yes you can shebang java scripts now).
Why do you need to remember that list of distinctions?

The beautiful thing about usrmerge is that there isn't really a
"standard" path. For all intents and purposes, /bin is the standard
path: it contains everything /usr/bin does, because that how symlinks
work.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 2:30 UTC (Wed) by milesrout (subscriber, #126894)
[Link]

You cannot assume that binaries are in particular places. This is why
you use "/usr/bin/env python".

[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 2:41 UTC (Wed) by dskoll (subscriber, #1630) [Link
]

That won't work if you need another argument on the commandline. For
example, this will fail:

#!/usr/bin/env awk -f
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 4:02 UTC (Wed) by wahern (subscriber, #37304) [
Link]

That's not a great example as you don't typically need to use -f like
that for shebang invocation of an awk script to work as expected.
That's literally why awk (and perl, python, etc) assume the first
non-option argument is the program file, and don't permute option
arguments in GNU fashion. (Am I missing a common awk
shebang-invocation pattern? Maybe you had in mind -F or -v?)

Sometimes Linux' behavior in this respect is annoying--other kernels
field split the shebang argument substring, at least up to some
limit, before appending the script path and original argument
vector--but I can't remember the last time I got bit by that. Maybe
trying to use `perl -w` instead of `use warnings` a couple weeks ago?
But that's because I'm stubborn. Didn't Perl 5 introduce `use
warnings` precisely to resolve this problem, or am I misremembering?

[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 5:02 UTC (Wed) by buck (subscriber, #55985) [Link]

Actually, the first non-option argument to awk is a literal awk
program; you do need to use -f if you are running an awk program/
script from a file.

Perhaps more edifying: the GNU version of env allows you to use a -S
option to get around the issue of the "shebang" line not being parsed
into multiple arguments; see https://man7.org/linux/man-pages/man1/
env.1.html#OPTIONS which has an example of a shebang line invoking
env to split up a perl command line so that perl's -w option can be
set.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 12:12 UTC (Wed) by dskoll (subscriber, #1630) [
Link]

Cool! I did not know about -S. Thanks!

[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 17:23 UTC (Wed) by jond (subscriber, #37669) [Link
]

Making your interpreter location portable by making your env-usage
non-portable
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 5:29 UTC (Wed) by josh (subscriber, #17465) [Link]

Part of the reason not to use things like `#!/path/to/interpreter
--option` is that if you invoke `interpreter thescript` you override
the shebang and don't get `--option`. This is, for instance, why
scripts should use `set -e` rather than `#!/bin/sh -e`.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 12:13 UTC (Wed) by dskoll (subscriber, #1630) [
Link]

In the specific case of awk, though, the -f is mandatory, whether
it's on the shebang line or by a direct command-line invocation.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 9:24 UTC (Wed) by ballombe (subscriber, #9523) [
Link]

> You cannot assume that binaries are in particular places.
Right, so env might not be in /usr/bin either.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 17:17 UTC (Wed) by fredex (subscriber, #11727) [
Link]

`which env` foobar
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 18:01 UTC (Wed) by excors (subscriber, #95769) [
Link]

Is that /bin/which or /usr/bin/which? Maybe it's safer to use `\
`which which\` env` foobar

(...except Debian recently wanted to deprecate which (https://lwn.net
/Articles/874049/) so that may not work either.)
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 2:55 UTC (Wed) by KJ7RRV (subscriber, #153595) [
Link]

Oh, okay, thank you. Does that mean /usr/local should be moved out of
/usr, since it likely shouldn't be shared?
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 3:36 UTC (Wed) by calumapplepie (subscriber, #
143655) [Link]

Fun fact: /usr/local isn't necessarily for local (ie, "this machine
only" or "unshared") packages. The Filesystem Hierarchy Standard, a
helpful document (but one which is regularally and happily ignored
when convenient) explicitly states that "It may be used for programs
and data that are shareable amongst a group of hosts". In other
words, /usr/local can live on a remote drive, as long as it isn't
overwritten by system software updates. On my system, the only files
in /usr/local were put there by Zotero (a citations manager for an
essay I am currently procrastinating on): Zotero is third-party
software, not provided directly through Debian, so it lives in /usr/
local even though it was installed by dpkg, since it isn't a part of
the distribution. If I was working on a machine with shared /usr,
that install would also be shared: which makes sense, since it's a
perfectly valid app.

TLDR: /usr/local can and should be shared. If you want your package
to live separately, see /opt/
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 4:16 UTC (Wed) by KJ7RRV (subscriber, #153595) [
Link]

Oh, okay, thank you!

[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 4:41 UTC (Wed) by calumapplepie (subscriber, #
143655) [Link]

No problem!
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 17:24 UTC (Wed) by jond (subscriber, #37669) [Link
]

Side-note that it's an odd choice for zotero's package to install
into /usr/local. The package manager protects you against clashing
paths in packages.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 17:46 UTC (Wed) by jccleaver (subscriber, #127418)
[Link]

That's one of several differences between Debian land and RedHat
land. Vendor packages obviously aren't supposed to write into /usr/
local/, but there's a strong incentive for custom-made packages not
to either, unless they really are a custom tarball of "local
scripts", or you've got other stuff locally that expects things to be
in /usr/local/

For all but the most trivial of packages, you almost always are
expected to use _bindir or _sbindir appropriately in your RPMs.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 18:13 UTC (Wed) by bluca (subscriber, #118303) [
Link]

It's the same in Debian, packages are really not supposed to ship to
/usr/local/. For third-party vendor, the canonical location is /opt/
<vendor> (see Chrome, Signal, and a bunch of other third party .deb
packages)
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 2:33 UTC (Wed) by Paf (subscriber, #91811) [Link]

I guess I'd like to hear why the merge is incorrect behavior. I see
how PATH can be used instead but I don't see any reason it's
incorrect.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 9:36 UTC (Wed) by anselm (subscriber, #2796) [Link
]

It is "incorrect" mainly because / and /usr have been separate for
almost 50 years - mostly because the PDP-11 the original Unix people
at Bell Labs were using had disks that were too small to hold the
content of both / and /usr on one drive, not because it was an
inspired design with obvious and far-reaching architectural
advantages -, and secondarily because the suggestion of merging them
comes from the person who is also responsible for systemd, which
implies that anything he says is automatically suspect.

[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 10:39 UTC (Wed) by pebolle (subscriber, #35204) [
Link]

Thanks for the link to Rob Landley's rant. I knew a rant like that
existed but couldn't find it. Great read, that should be read before
reading this article, to fully grasp the absurdity of this situation.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 17:54 UTC (Wed) by jccleaver (subscriber, #127418)
[Link]

>the suggestion of merging them comes from the person who is also
responsible for systemd, which implies that anything he says is
automatically suspect.

Anything LP says *is* automatically suspect, or should be. The
systemd cabal has been the source of more needless sysadmin misery
than any other aspect of Linux in the last 12 years, and the fact
that it was snuck in (on the RH side) as a nearly-invisible
transition just like the swap to upstart had been from EL5->EL6
doesn't help with his trustworthiness. (Nor, indeed, does his history
before that, but that's a separate matter.)

systemd is the ur-example of the slippery slope, and this extended
pain demonstrates how far that slope goes. This was from 2019 in
Fedora, but I wouldn't be surprised if there were still more
landmines out there thanks to this... https://bugzilla.redhat.com/
show_bug.cgi?id=1691825
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 3:25 UTC (Wed) by flussence (subscriber, #85566) [
Link]

Perhaps they could solve this the Debian way by having a script that
consolidates all contents either into or out of /usr/, and the
behaviour is controlled by `update-alternatives`...
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 7:17 UTC (Wed) by dilinger (subscriber, #2867) [
Link]

Hm, so /usr/bin and /bin (as well as the respective sbin and lib
directories) are all symlinks into /etc/alternatives, and /etc/
alternatives/will-the-real-bin-please-stand-up points to either /usr/
bin.traditional or /bin.traditional depending on what you've
configured in debconf? I like it!

brb, whipping up a patch :D
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 6:56 UTC (Wed) by digwer (subscriber, #123427) [
Link]

I have not seen "Filesystem Hierarchy Standard" mentioned anywhere
here and I think that these changes does not comply with it.
Is FHS still relevant, or is it just obsolete standard that no one
cares about?
[Reply to this comment]
Filesystem Hierarchy Standard

Posted Apr 6, 2022 8:32 UTC (Wed) by matthias (subscriber, #94967) [
Link]

Please be more specific. Where do the changes not comply to the FHS?
The FHS explicitly allows any of the standard entries to be symlinks
to directories instead of directories. And it only specifies which
files have to exist in some location (e.g. /bin or /usr/bin). It does
not require that the files are not accessible through the other path.
[Reply to this comment]
Filesystem Hierarchy Standard

Posted Apr 6, 2022 10:38 UTC (Wed) by digwer (subscriber, #123427) [
Link]

Indeed, You are right: '/bin' can be symlink to somewhere else.
Doh! Sorry about that.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 13:00 UTC (Wed) by smoogen (subscriber, #97) [Link
]

On the other side, the committees behind the FHS, LSB and some other
standards have been mostly dead since around 2015. This has led to it
becoming a standard where some proclaim it as G-d's word written
down, and unchanging and others to proclaim it that it is no longer
useful. Thus leading to all the usual religious wars one can expect.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 14:28 UTC (Wed) by flussence (subscriber, #85566)
[Link]

They're all feature checklist items, like FIPS, that exist for those
that can't function without checklists.

These paper standards aren't nearly as important as the undocumented
meta-standards for how to cope with systems that don't follow them in
the first place, as those are what everyone* ends up using anyway.
Things like pkgconf, LD_PRELOAD, autotools (blegh) and its
replacements (and their replacements, and...).

[*] a well-behaved subset of "everyone", anyway. I've recently had to
deal with distro-packaging an app that hardcodes everything to be in
the same directory as the main binary...
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 8:26 UTC (Wed) by bluca (subscriber, #118303) [
Link]

While being a good summary of recent events, I think the article
missed the most important aspect of all this: the real issue is not
about technical design (that debate settled 10 years ago, now it's
just a question of the stragglers catching up), or the technical
implementation (we know what we got works, Ubuntu does it and it
hasn't fallen apart). The question is social, and about project
management. The Debian constitution, that all project members have to
follow, states that the Technical Committee makes decisions regarding
the technical direction of the project, and while it cannot force
individuals to work on anything, individual maintainers are not
allowed to veto decisions they don't personally like and block the
entire project. And yet that's exactly what's happening here.

So the important questions it would have been interesting to see
explored from an outsider's perspective are, how does/can a volunteer
project based on bureaucracy like Debian deal with dissent or even
obstructionism? Can the project make effective decisions and
implement then, whatever they might be, given its self-imposed rules
and customs and the practical reality of how volunteers take care of
specific parts of the projects as their own thing? Are there similar
situations in other projects/distros? And so on.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 9:49 UTC (Wed) by ballombe (subscriber, #9523) [
Link]

The real issue is that the TC is not a steering committee that is
empowered to decide long term project orientation on behalf of the
project. This is by design.

The TC should not have decided the usrmerge issue before all the
relevant patches were available. Since the TC cannot force anybody to
implement anything, what the TC really decided is that bookworm
should be delayed indefinitely until someone implement usrmerge. This
is not sustainable.

Helmut Grone called it correctly.
If a GR was put to vote whether or not to delay bookworm for usrmerge
would likely fail.

[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 9:55 UTC (Wed) by bluca (subscriber, #118303) [
Link]

Changes in dpkg are nice to have but not necessary, so what you are
saying is incorrect, there is already an available path forward. The
decision could be made today to do the same thing Ubuntu has done
successfully last year, make the usrmerge pseudo-essential, and move
on from there. We know this works, or Ubuntu wouldn't exist anymore.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 11:00 UTC (Wed) by ballombe (subscriber, #9523) [
Link]

But nobody offered to the TC to do this work at the time, so my point
stand.
It is not the first TC decision to have been ignored because nobody
was willing to do the work.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 11:18 UTC (Wed) by bluca (subscriber, #118303) [
Link]

That's also inaccurate, it was proposed multiple times to follow
Ubuntu's example and make usrmerge pseudo-essential. It's a really
trivial change to do, what's missing is the indication from the TC to
do it, not the work to implement it.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 10:59 UTC (Wed) by pebolle (subscriber, #35204) [
Link]

> Are there similar situations in other projects/distros?

This is, as the article says, "Debian, being Debian".

I've come to the view that for a certain number of people things like
discussions taking the better part of a decade, endless threads on
countless lists, resolutions of thousands of words, voting, and what
not are a feature of Debian, not a bug. Some people actually enjoy
being part of that. And apparently quite a number of those people
ended up running Debian.

(Clearly there are also people in Debian doing all the other stuff
needed to keep Debian going. I expect that most of the people in the
let's-do-mock-United-nations group are probably in the do-the-work
group too.)
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 13:14 UTC (Wed) by mgedmin (subscriber, #34497) [
Link]

> we know what we got works, Ubuntu does it and it hasn't fallen
apart

While it hasn't fallen apart completely, there are minor buglets here
and there, e.g. dpkg -S $(which $thing) fails to find the package
containing some binaries.

I personally haven't noticed anything else, and I think this will be
fixed once Debian drops support for non-usr-merged system and
migrates all the buildbots, so the built packages no longer declare
that they contain files from /bin or /lib.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 14:45 UTC (Wed) by mbunkus (subscriber, #87248) [
Link]

"dpkg -S" has never been perfect:

[0 mbunkus@reliant ~] dpkg -S $(which vim)
dpkg-query: no path found matching pattern /usr/bin/vim

/usr/bin/vim is a symlink to the alternatives system. In my case the
actual binary is vim.basic, and that one is found by dpkg. You have
to know about this system already, and having one more thing to know
isn't really the sky falling in my opinion.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 15:08 UTC (Wed) by ianmcc (subscriber, #88379) [
Link]

That seems like it ought to be a fairly simple fix too - if the
target isn't found in the database and it is a symlink, then chase
the symlink and see if the target is in the database (rinse and
repeat as required).
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 15:13 UTC (Wed) by mbunkus (subscriber, #87248) [
Link]

True, and that it hasn't happened shows that users generally don't
really care. My guess is that they'll care about "dpkg -S" not
finding /bin/bash (when it's really /usr/bin/bash with /bin - /usr/
bin) just as much: not really.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 19:02 UTC (Wed) by sobkas (subscriber, #40809) [
Link]

I once wrote a tool to unbreak my system after a long habit of using
make install on /usr and or /.
It checked if hash of a file was identical to one in dpkg database
and if not it would reinstall package.
It also deleted files that were not part of any package. Surprisingly
it didn't brake my system and allowed Gnome to start again.
It was so long time ago, but then I just started to package changes
that I needed instead of using make install.


[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 17:30 UTC (Wed) by jond (subscriber, #37669) [Link
]

I'd like to see -S's behaviour wrt symlinks fixed, rather than used
as an excuse to ignore other bugs.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 17:27 UTC (Wed) by jond (subscriber, #37669) [Link
]

The article does quote Russ refuting the "Ubuntu haven't had
problems" argument.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 17:43 UTC (Wed) by bluca (subscriber, #118303) [
Link]

Which I find very unconvincing, as stated <somewhere>. Ubuntu has
plenty of downstream packages, and yet this assumed urge to move
things around in just the right (or wrong?) way hasn't happened
there. If anything, the current TC ban on the specific change that
triggers the feared behaviour can be just kept in place until the
dpkg maintainer accepts the project-wide change. It's been in place
since last year and we seem to be doing fine with it. If fixing dpkg
is not possible, and it doesn't look like it is for social reasons
more than technical ones, it doesn't seem like a bad solution to
finish the transition and move on.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 9:46 UTC (Wed) by sobkas (subscriber, #40809) [
Link]

I saw warning and it advised me to use dpkg-fsys-usrunmess:
But now I see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=
1008486
And even without that there are problems with that tool:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991218
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991192
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008316
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008478

Now what I'm supposed to do? Wait for dpkg-fsys-usrunmess-unmess?
Is my system broken because I have used dpkg-fsys-usrunmess(that dpkg
advised me to do?).
As a Debian user I'm confused and a bit angry. What is a way forward?
Because apparently no one knows.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 14:49 UTC (Wed) by wsy (subscriber, #121706) [Link
]

I almost ran dpkg-fsys-usrunmess-unmess on my system after seeing the
dpkg warning. Luckily I tried --dry-run first and felt too risky
seeing all the files it touched.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 19:40 UTC (Wed) by mb (subscriber, #50428) [Link]

I recently converted my affected system by running
dpkg-fsys-usrunmess in a root console (not X terminal emulation) in
multiuser mode with X running in the background.
It worked just fine.

I also have a selfbuilt kernel installed. But it's properly built and
installed as deb package. It converted that just fine, too.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 10:25 UTC (Wed) by aragilar (subscriber, #122569)
[Link]

Who maintains dpkg in Ubuntu (and other derivatives) currently?
Looking at the changelog in impish, it looks like Adam Conrad was up
to 2019, and Matthias Klose has uploaded more than most based on
cursory scan, but there doesn't appear to be one (as I would be
really curious what their view of merged-usr is)?
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 10:43 UTC (Wed) by bluca (subscriber, #118303) [
Link]

Ubuntu enforces the switch to merged-usr since 21.10 for all
installations, old and new
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 15:38 UTC (Wed) by juliank (subscriber, #45896) [
Link]

We prefer to think of the team as the maintainer rather than an
individual. Patching dpkg for better usrmerge usability is on our
minds, certainly.

I think we are all strong proponents of merged-usr.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 10:55 UTC (Wed) by IanKelling (subscriber, #89418)
[Link]

So, common thing, as a normal user, /sbin wasn't in my PATH, so I
added
it, and then I added /usr/sbin. Now, suddenly under the usr merge,
I'm
getting /usr/sbin binaries looked up as /sbin. I'd rather that not
happen.

Making every executable have 2 paths, both equally valid, adds
significant complexity to the system. In general for software system
design, people try hard to avoid duplicating things like that. So, I
see
the appeal of the symlink farm of just needed files, which is like 1%
of
the files that would gain a symlink in comparison to the directory
symlinks. Ideally, both options would be supported. In the Fedora
document, it says they actually used the symlink farm to do their
transition, then removed it once it was done. Too bad.

[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 15:35 UTC (Wed) by juliank (subscriber, #45896) [
Link]

You have it to wrong way around. By making /bin -> /usr/bin and so
on, complexity is reduced - you can use both paths equally.

If you only had a symlink farm, /usr/bin/bash would still be wrong.

This also improves portability with (from) systems that are not
usrmerged but do have bash in /usr/bin.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 19:43 UTC (Wed) by IanKelling (subscriber, #89418)
[Link]

> If you only had a symlink farm, /usr/bin/bash would still be wrong.

I don't understand why, perhaps I'm missing something obvious? In the
symlink farm, you have /usr/bin/bash, and the symlink /bin/bash -> /
usr/bin/bash. That doesn't seem obviously any different for a bash
user than in the normal usr merge symlink /bin -> /usr/bin.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 20:05 UTC (Wed) by bluca (subscriber, #118303) [
Link]

Because /bin is no longer a symlink to /usr/bin, which means anything
that installs to /bin (external repositories, language package
managers, sudo make install, curl | sudo bash, etc) will not follow
the specification. Which means the transition will be forever
half-done and never finished, which means it will be worse than not
doing it at all - software can't rely on the locations being
identical, and you get all the drawbacks of having to do work to
implement it half-way.

SUSE tried that for a few years, it did not work out, they had to
spend a lot of time and effort to undo it, before finally moving to
proper merged-usr. It would be a very bad idea to ignore history like
that.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 14:15 UTC (Wed) by Thalience (subscriber, #4217) [
Link]

The whole "My package, my precious" attitude of many Debian
Developers is really the worst thing about the project. The
second-worst thing about Debian is the lack of any real way to deal
with the first problem. Collaboration becomes impossible when
obstructionism is tolerated.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 15:41 UTC (Wed) by calumapplepie (subscriber, #
143655) [Link]

Strong package ownership isn't a problem. I am the expert in my
package: if you want to make changes, you should go through me, to be
sure you don't break anything. If I'm doing work, I don't want that
work to be messed up by someone making a 'fix' that conflicts with
mine.

Their are processes to deal with stubborn maintainers: however, you
can't force them to do work.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 17:09 UTC (Wed) by jeltz (guest, #88600) [Link]

If there are processes for dealing with stubborn package maintainers
why have they not been invoked in this case? To me as an outsider it
seems like the current maintainer of dpkg is being stubborn and
blocking patches for people who have done the work (e.g. Ubuntu's
dpkg maintainers who have managed to pull off the same merge). So it
is not about forcing people to work.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 19:01 UTC (Wed) by smoogen (subscriber, #97) [Link
]

The maintainer for certain packages are also the upstream of said
packages. In such cases even if the 'maintainer' was moved, it would
still have the upstream to deal with.

Things take a long time in Debian by design. It is pretty much a
'they who live longest, win' do-ocracy. You do what you want until
you don't want to do it anymore and if people didn't like it they
could either come up with a replacement package, a replacement system
or a replacement OS (aka moved to something else). In the end, this
goes back to the core reason Debian exists for many people, to be the
arbitrator of 'licensing' decisions ( https://lwn.net/Articles/884301
/ ) and that means it is more like a law journal than a fast running
OS distributor. I say a law journal because in the end it is
important to have a good argument which may be used by someone else
later or to be counter argued years later . Those arguments are
important and have shaped a lot of long term thinking in both Open
and Closed source software in the last 3 decades. However also as a
law journal, there is rarely a closed case. Things will be
relitigated as people come up with different ideas and concerns.

The problem is that these arguments and relitigations also extend to
what some people think is what Debian is for.. writing an OS.
[Reply to this comment]
Debian still having trouble with merged /usr

Posted Apr 6, 2022 17:39 UTC (Wed) by atnot (subscriber, #124910) [
Link]

> however, you can't force them to do work

That this would be needed in the first place is precisely the issue
though. In a model where the project collectively owns packages and
the maintainer is merely a steward or primary point of contact for
it, there would be no need to force anyone to do any work.

In such a model, standardization means less work for you and
cooperation is beneficial lest your decisions be overridden by
others. Meanwhile in Debian's model, standardization increases your
workload without any benefits, and being uncooperative reduces your
personal maintainance burden.
[Reply to this comment]

                  Copyright (c) 2022, Eklektix, Inc.
   Comments and public postings are copyrighted by their creators.
          Linux is a registered trademark of Linus Torvalds