Bug#985502: release-notes: suggestions for usrmerge section

Hi,

Post by Justin B Rye
Package: release-notes
Severity: wishlist
Tags: patch
Trying to make our coverage in issues.dbk more helpful.

Historically there was a reason to split root level
<filename>bin</filename>, <filename>sbin</filename> and
<filename>lib</filename> directories into

Nobody ever split /bin etc. "into" /usr; the historical standard was
to have those directories to split things "out from" the equivalents
under /usr.

When I read that the first three times, I read it the opposite of what I
meant, can we improve even further?

<filename>/usr/</filename>, but that is no more.

Unclear; say "but this justification no longer applies today".

Ack.

Post by Justin B Rye
Preferably this bald assertion would go with a link to an explanation;
and I suppose that has to be
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
(unless the Debian Wiki version suddenly gets much better).

I really liked this (linked from that page):
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html but
I guess it doesn't make a strong link.

Debian
bullseye will be the last Debian release that supports the
non-merged-usr layout.

Unless the plan is for the bookworm Release Notes to tell users with
legacy layouts that they can't upgrade, we should be pointing at
usrmerge here.

We have bug #841666 for that? It wasn't concluded there yet. And I'd
expect we'll force the upgrade then, not something users would need to
actively do.

This patch is the first place where we <quote> a release name. Do we
want quotes everywhere? I personally don't like to quote bullseye or
buster, but emphasizing sounds OK. And indeed, I wasn't consistent with
"Debian bullseye" here, maybe that should have been plain "bullseye"
(without quotes ;))

Paul

Justin B Rye

2021-03-19 18:40:01 UTC

Historically there was a reason to split root level
<filename>bin</filename>, <filename>sbin</filename> and
<filename>lib</filename> directories into

Nobody ever split /bin etc. "into" /usr; the historical standard was
to have those directories to split things "out from" the equivalents
under /usr.

When I read that the first three times, I read it the opposite of what I
meant, can we improve even further?

How about:

The historical justifications for the filesystem layout with
<filename>/bin</filename>, <filename>/sbin</filename>, and
<filename>/lib</filename> directories separate from their
equivalents under <filename>/usr</filename> no longer apply
today; see

[...]

http://lists.busybox.net/pipermail/busybox/2010-December/074114.html but
I guess it doesn't make a strong link.

Yes, I wish the official versions were even half as persuasive as that
one. I could try to fix up the Debian Wiki page, but I'd rather not.

Debian
bullseye will be the last Debian release that supports the
non-merged-usr layout.

Unless the plan is for the bookworm Release Notes to tell users with
legacy layouts that they can't upgrade, we should be pointing at
usrmerge here.

We have bug #841666 for that? It wasn't concluded there yet. And I'd
expect we'll force the upgrade then, not something users would need to
actively do.

Do we have a proposed mechanism for that? Is usrmerge going to be
made Essential (but a no-op on already-merged systems), or what?

The problem with this announcement that the End of the Legacy
Filesystem Layout Is Nigh is that users get no clue what they're
meant to *do* about it. My own desktop has been upgraded in place
since Wheezy; unless I'm finally going to be switching onto new
hardware, I'd prefer to plan in terms of doing two separate steps, a
usrmerge in 2022 and a dist-upgrade in 2023.

A vaguer version:

summary</ulink>. Debian bullseye will be the last Debian
release that supports the non-merged-usr layout, so systems
with an unmerged layout that have been upgraded without a
reinstall should consider installing the package
<systemitem role="package">usrmerge</systemitem>.

Post by Paul Gevers
This patch is the first place where we <quote> a release name. Do we
want quotes everywhere? I personally don't like to quote bullseye or
buster, but emphasizing sounds OK. And indeed, I wasn't consistent with
"Debian bullseye" here, maybe that should have been plain "bullseye"
(without quotes ;))

We could use &debian; &releasename;, of course - I moan about how
pointless it is when we know it'll only be true for one release, but
at least it takes care of standardised formatting.

--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Paul Gevers

2021-03-19 20:00:02 UTC

Hi Justin,

Post by Justin B Rye
The historical justifications for the filesystem layout with
<filename>/bin</filename>, <filename>/sbin</filename>, and
<filename>/lib</filename> directories separate from their
equivalents under <filename>/usr</filename> no longer apply
today; see

Yes.

Post by Justin B Rye
Yes, I wish the official versions were even half as persuasive as that
one. I could try to fix up the Debian Wiki page, but I'd rather not.

Ack :).

Post by Justin B Rye
Debian
bullseye will be the last Debian release that supports the
non-merged-usr layout.

Unless the plan is for the bookworm Release Notes to tell users with
legacy layouts that they can't upgrade, we should be pointing at
usrmerge here.

We have bug #841666 for that? It wasn't concluded there yet. And I'd
expect we'll force the upgrade then, not something users would need to
actively do.

Do we have a proposed mechanism for that? Is usrmerge going to be
made Essential (but a no-op on already-merged systems), or what?

I'm not aware of the ideas on this front....

Post by Justin B Rye
The problem with this announcement that the End of the Legacy
Filesystem Layout Is Nigh is that users get no clue what they're
meant to *do* about it. My own desktop has been upgraded in place
since Wheezy; unless I'm finally going to be switching onto new
hardware, I'd prefer to plan in terms of doing two separate steps, a
usrmerge in 2022 and a dist-upgrade in 2023.
summary</ulink>. Debian bullseye will be the last Debian
release that supports the non-merged-usr layout, so systems
with an unmerged layout that have been upgraded without a
reinstall should consider installing the package
<systemitem role="package">usrmerge</systemitem>.

...so I'm a bit reluctant on this front.

We could use &debian; &releasename;,

But those are also meant to be used in e.g., filenames, so are unquoted,
unliteral, un...

of course - I moan about how

Post by Justin B Rye
pointless it is when we know it'll only be true for one release, but
at least it takes care of standardised formatting.

Yes, I refrain from using these entities in new not-reusable text
conform bug #927679.

Paul

Justin B Rye

2021-03-20 08:30:02 UTC

Paul Gevers wrote
[...]

Post by Justin B Rye
Do we have a proposed mechanism for that? Is usrmerge going to be
made Essential (but a no-op on already-merged systems), or what?

I'm not aware of the ideas on this front....

[...]

Post by Justin B Rye
summary</ulink>. Debian bullseye will be the last Debian
release that supports the non-merged-usr layout, so systems
with an unmerged layout that have been upgraded without a
reinstall should consider installing the package
<systemitem role="package">usrmerge</systemitem>.

...so I'm a bit reluctant on this front.

Remember that at present not only do we fail to mention the word
"usrmerge", the page we're planning to add a pointer to is one that
doesn't get users any closer to finding out about it. We might as
well be saying:
Support for the non-merged-usr layout will be dropped
after Debian bullseye, so all users are doomed. DOOMED!

--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Justin B Rye

2021-03-20 17:10:01 UTC

Post by Justin B Rye
Remember that at present not only do we fail to mention the word
"usrmerge"

I'd forgotten the *Buster* release notes *do* mention usrmerge:

https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.html#merged-usr

but we've taken that part out now. Could we perhaps recycle the
phrase "the usrmerge package exists to do the conversion if desired"?

--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Paul Gevers

2021-03-20 19:40:01 UTC

Post by Justin B Rye
Remember that at present not only do we fail to mention the word
"usrmerge"

https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.html#merged-usr
but we've taken that part out now. Could we perhaps recycle the
phrase "the usrmerge package exists to do the conversion if desired"?

Sounds like a plan.

Paul

Justin B Rye

2021-03-21 11:40:02 UTC

Post by Justin B Rye
https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.html#merged-usr
but we've taken that part out now. Could we perhaps recycle the
phrase "the usrmerge package exists to do the conversion if desired"?

Sounds like a plan.

That would give us something like the attached...

--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Debian Bug Tracking System

2021-03-23 21:30:03 UTC