Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Michael Biebl]

Hi Guillem

Am 19.07.21 um 03:36 schrieb Guillem Jover:

What I've also said multiple times, is that
merged-usr-via-moves-and-symlink-farms could have been implemented in
a fully automated way, by debhelper, w/o requiring any maintainer scripts,
all with full cooperation and managed by dpkg, with .debs shipping
actual tracked pathnames
I'm convinced this view is way too naive and not implementable in 
practice (and yes, openSUSE is a data point that confirms that)


What you propose is, that each and every package does its /usr-merge 
transition on its own. This only works, if packages are independent 
(enough) so this actually works.
Unfortunately this is not the case. Take PAM for example. You can't just 
recompile src:pam and have debhelper automatically move all files to 
/usr. This would break all packages that install a PAM plugin. You have 
a transition here, involving many packages.
Same is true for udev rules, systemd service files, basically every 
package that provides interfaces/hooks to other packages is affected.

So it's not that simple unfortunately. You can't fully automate that.

According to
apt-file search -x '^/(lib|bin|sbin)'
on my Debian sid/amd64 system, we have 1747 packages shipping 24583 
files in those directories. There are *many* such entangled transitions 
hidden in there, so I fear this is not manageable.
As Luca pointed out, even distros with a much stricter governance model 
were not able to do that.


The /usr-merge transition as described and decided on in the TC bug, 
seems to me is the only viable way forward.


Yes, it does break dpkg -S, but your idea of using a list of mapped 
paths as in [1] seems like an entirely reasonable approach to solve this.


Once we have this global switch to merged-usr, packages can bit by bit, 
completely independent, update their debian/rules to use --prefix=/usr 
and after a few years, we don't have any packages anymore installing any 
files in /. We could aid this process with a lintian check that flags 
packages that install files in /(sbin|bin|lib)/.





Regards,
Michael


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858331#33




OpenPGP_signature
Description: OpenPGP digital signature

Re: merged /usr

[Simon McVittie]

On Mon, 19 Jul 2021 at 11:33:49 +0200, Stephan Lachnit wrote:
> We could start with collecting the packages that install to /bin*
> instead of /usr/bin, and adjust the packaging so that they don't do
> that. [...] At this point, it shouldn't
> matter if you run a merged usr system or not, or am I forgetting
> something?

This would have part of the practical effect of merged-/usr, but not all
of it. It could still be a useful step forwards, but we should not view
it as being entirely equivalent to merged-/usr.

What we have now on unmerged-/usr systems, using /bin/bash and
/usr/bin/perl as examples of Essential programs that use the two paths:

 bashperl
/bin/foo   physical location   (does not exist)
/usr/bin/foo   (does not exist)physical location

What we would have on unmerged-/usr systems if we do as you suggest:

 bash perl
/bin/foo   exists via symlinks  (does not exist)
/usr/bin/foo   physical locationphysical location

Merged-/usr for comparison:

 bash perl
/bin/foo   exists via symlinks  exists via symlinks
/usr/bin/foo   physical locationphysical location

As you can see from those tables, a package that hard-codes /usr/bin/bash
is currently considered broken, but would work with either your proposal
or merged-/usr. Conversely, a package that hard-codes /bin/perl would
still be considered broken, would *not* work with your proposal, but
would work on merged-/usr systems.

(Obviously the same applies when considering hard-coded paths in /sbin,
/lib, etc. instead of /bin, in particular the ELF interpreters like
/lib64/ld-linux-x86-64.so.2 that are hard-coded into every
dynamically-linked executable)

Meanwhile, various shared libraries are also moving from /lib to
/usr/lib.  One potentially serious problem with that on non-merged-/usr
systems is that we still don't understand why the bugs discussed
in https://bugs.debian.org/911225 and https://bugs.debian.org/949395
happened, and a similar thing could potentially happen to /lib libraries
other than GLib. The script that GLib uses to work around this is generic,
and could be used in other affected packages if required, but it's larger
and more fragile than I'm really comfortable with.

(Merged-/usr systems cannot suffer from bugs like the ones discussed in
#911225, because the paths involved are the same directory.)

smcv

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Stephan Lachnit]

On Mon, Jul 19, 2021 at 3:37 AM Guillem Jover  wrote:
> What I've also said multiple times, is that
> merged-usr-via-moves-and-symlink-farms could have been implemented in
> a fully automated way, by debhelper, w/o requiring any maintainer scripts,
> all with full cooperation and managed by dpkg, with .debs shipping
> actual tracked pathnames, if it had not been for the mess required
> by merged-usr-via-aliased-dirs. :/

Maybe I get this wrong, but I don't think this conflicts with the
decision from the TC.

Until Debian 12 gets released, we have a lot of time for a transition.
Maybe we should start discussing the transition and less whether or
not we do it, as this has been decided now anyway.

We could start with collecting the packages that install to /bin*
instead of /usr/bin, and adjust the packaging so that they don't do
that. Of course, we would need to add a maintainer script that detects
un-merged usr and creates a symlink. Actually, I think it would be
enough to just let debhelper detect if a package installs to /bin, and
adjust the package automatically. For packages not using debhelper,
lintian can add a warning if the package installs to /bin. After all
packages that installed to /bin have been rebuilt, nothing would
install to /bin except for symlinks. At this point, it shouldn't
matter if you run a merged usr system or not, or am I forgetting
something? IMHO it would make way more sense to discuss how to merge
usr once the packages are fixed.

Anyway, I think the discussion made clear that we shouldn't
immediately start with merging usr once bullseye is released, and I
wouldn't interpret the TC decision as such.

Regards,
Stephan

* using /bin as an example, same goes for /lib etc

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Marco d'Itri]

On Jul 19, Marc Haber  wrote:

> I am NOT looking forward having to manually convert legacy systems to
> merged /usr and I do sincerely hope that Debian will choose a way to
> get away without throwing away systems that have just a small /, still
> supporting a dedicated /usr as long as it's mounted by initramfs. I am
They cannot be supported without keeping a lot of unneeded complexity 
around, but there is no reason to reinstall them: you can move / inside 
/usr instead. You may use either sash or a live CD image.

> I also believe that smaller file systems are unlikely to break and
> that a system that can boot up to a ssh-able state even with a broken
> file system is way easier to fix. We have taken a huge step back in
And "apt install grml-rescueboot" is even better.
Also, with merged-/usr you may keep your *whole* OS in a read only file 
system.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Gunnar Wolf]

As I said, on a separate mail...

Marc Haber dijo [Mon, Jul 19, 2021 at 07:12:24AM +0200]:
> In an ideal world, would the package manager not be a service utility
> to SUPPORT policy and adapt to changing environment contitions instead
> being a showstopper for innovation?
> 
> Who is the dpkg maintainer to challenge the decisions of the entire
> project? I fully understand that there is only ONE dpkg maintainer,
> but a utility THIS central to the entire ecosystem not being team
> maintained is a HUGE part of the problem.
> 
> And no, I cannot help and no, you wouldn't want me to write a single
> line of code in a package THIS central.
> (...)
> Would it not be dpkg's job to work around these flaws? It's not that
> every other component of a Debian system are perfect.

FWIW, I mostly agree with what you say here -- If the project decides
to a new standard (and, in this case, it has via the TC's decision --
which can of course be repealed by GR, if things come to that),
packages that behave differently... are buggy and should be fixed.

Of course, dpkg is a very special case for obvious reasons; I did try
to reach out to Guillem when we started discussing the bug at the TC,
and was disheartened by his harsh reply basically negating all
possibility of discussion because his non-belief in the TC itself.

There are technical issues that this migration will bring, and yes,
there is a nonzero chance some users will be bitten by the dissonance
between dpkg and reality. But after two TC bug resolutions (#914897
and #978636), and after lots of bytes have been spilled by various
people, I can only see work has to be put into making possibly
problematic cases less likely -- rebuilding and checking packages
don't ship files in the root directories will cover a great deal of
the distance. If aliasing the directories via symlinks is so messy,
well... we should focus on the root cause, and fix the rasons for it
to be broken as much as we can. The symlinks could probably be an
unconsequential footnote if this is done right.


signature.asc
Description: PGP signature

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Gunnar Wolf]

Sorry to single you out here, Marc -- This goes to many people. This
goes, in fact, to the discussion itself.

Marc Haber dijo [Mon, Jul 19, 2021 at 07:12:24AM +0200]:
> In an ideal world, would the package manager not be a service utility
> to SUPPORT policy and adapt to changing environment contitions instead
> being a showstopper for innovation?
> 
> Who is the dpkg maintainer to challenge the decisions of the entire
> project? I fully understand that there is only ONE dpkg maintainer,
> but a utility THIS central to the entire ecosystem not being team
> maintained is a HUGE part of the problem.
> 
> And no, I cannot help and no, you wouldn't want me to write a single
> line of code in a package THIS central.
> (...)

While I agree with what you write here (will answer on a separate
mail), I'll ask you -and everybody- to please moderate the tone. It is
frustrating to speak in different wavelengths and not be able to hear
one another, but we are not going to get anywhere if we just SHOUT
LOUDER using our same wavelength. We must find some alternate
frequencies to get to a constructive situation.

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Stephan Verbücheln]

Nowadays you can also have BTRFS subvolumes, which does not require you
to define sizes in advance. In that case it is nice for snapshotting to
have separate subvolumes for things like home directories.

Regards

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Marc Haber]

On Sun, 18 Jul 2021 16:21:24 -0700, Russ Allbery 
wrote:
>I agree with the other feedback that you are overpartitioning your disk.

It is especially evident in the df output where there are two-digit
amounts of gigabytes free on most of those HUGE partitions.

>I used to do this back when I was first learning UNIX in the 1990s because
>it seems like a good idea and it does isolate one part of the system from
>another if it uses an excessive amount of space.  But what I found in
>practice, and what almost everyone who does this eventually finds in
>practice, is that this much partitioning drastically reduces the long-term
>flexibility of the system.  It requires you predict in advance what parts
>of the system will grow, and when you guess wrong, you end up with
>symlinks trying to move directories from a partition with no free space to
>another partition with free space, with all the complexity and breakage
>that can cause.

Nowadays, with LVM, file systems can easily grow, even online. I have
stopped putting /usr on a dedicated file system as the usrmerge began
to show up on the horizon, but I still use dedicated file systems for
/home and /var.

I am NOT looking forward having to manually convert legacy systems to
merged /usr and I do sincerely hope that Debian will choose a way to
get away without throwing away systems that have just a small /, still
supporting a dedicated /usr as long as it's mounted by initramfs. I am
not sure whether we ever issued a clear statement about that.

>There are some technical reasons to separate /boot if you are using a file
>system for other partitions that isn't suitable for early boot (or if
>you're using cryptsetup or other file system layers).  /boot/efi is always
>a separate partition because of how it works.  Apart from those two
>special cases, the only reason to put something on a separate file system
>is if you have a clear and compelling reason why you expect a given file
>system to run out of space and you want to ensure that it cannot take
>space from other parts of the system.

I also believe that smaller file systems are unlikely to break and
that a system that can boot up to a ssh-able state even with a broken
file system is way easier to fix. We have taken a huge step back in
that regard with systemd since the systemd rescue mode requiring the
"real" root password even for minor startup failures is way more
unfriendly than what we had before. Many installations closely guard
the root password for real emergencies (I have been working on big
installations for years and have NEVER seena case where the "real"
root password was actually used - it is usually easier to rebuild
affected systems from scratch).

>This can be a good justification for putting /home on a separate partition
>*if* you are running a multi-user system.  But otherwise, separating out
>things like /var or /usr/local or /opt or /srv is more likely to cause you
>long-term headaches than it is to do anything useful.

I disagree for /var (maybe just for /var/log or parts of /var/lib).

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Marc Haber]

On Mon, 19 Jul 2021 03:36:59 +0200, Guillem Jover 
wrote:
>If by "very minor bugs" you mean that f.ex.:
>
> * dpkg, dpkg-divert, or update-alternatives are unable to detect file
>   conflicts and thus might allow silent overwrites of random stuff on
>   disk,
> * when moving files across packages and across aliased directories,
>   these pathnames might end up disappearing depending on the unpack
>   order,
> * dpkg-deb -x on the root directory (yes, people use this to recover
>   systems) with any .deb that contains files on real directories under
>   «/», will replace the symlinked directories with real ones,
>
>then, yes, I guess "very minor" indeed. But then I completely object
>to this being classified as bugs in dpkg, as this has been shoved in
>disregarding that dpkg does *not* support this, and it would require
>new *features* to be implemented, so this "transition" is founded on
>assuming features that do not exist, or completely going behind
>dpkg's back, which sounds great I guess…

In an ideal world, would the package manager not be a service utility
to SUPPORT policy and adapt to changing environment contitions instead
being a showstopper for innovation?

Who is the dpkg maintainer to challenge the decisions of the entire
project? I fully understand that there is only ONE dpkg maintainer,
but a utility THIS central to the entire ecosystem not being team
maintained is a HUGE part of the problem.

And no, I cannot help and no, you wouldn't want me to write a single
line of code in a package THIS central.

>The problem in general is that this layout introduces unreliability
>and silently induced breakage stemming from this flawed filesystem
>layout, which is going to affect the people that are going to benefit
>the less from its properties, and are the less experience to deal with
>it.

Would it not be dpkg's job to work around these flaws? It's not that
every other component of a Debian system are perfect.

>And here we are getting the project installing by default systems that
>are fighting the packaging system and going on its back, to enable a
>filesystem design layout mostly experienced admins will benefit from
>in very special deployment conditions, where final users can very
>easily suffer from its introduced unreliability (from 3rd-party repos
>or locally built packages, etc, f.ex.).

I must be missing some thing, but isn't it the experienced admins
facing reinstalls of vital systems when we finally move to a
completely merged /usr, because these usually currently have /usr on a
dedicated mountpoint?

>Because the above has been brought up before and the proponents are well
>aware of these, I'm afraid at this point the only thing that comes to
>mind is negligence, TBH. :/

on both sides of the conflict, yes.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Russ Allbery]

Polyna-Maude Racicot-Summerside  writes:

> I had the belief that some software used /tmp for temporary file that
> may grow many GB (example DVD creation).

> I have 32 GB

It should not, or at least it should let you specify a different path,
because using tmpfs for /tmp is very common these days.  (/var/tmp is
available if one needs a file system more likely to be on a larger disk.)

-- 
Russ Allbery (r...@debian.org)  

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Guillem Jover]

On Thu, 2021-07-15 at 10:13:47 +0100, Luca Boccassi wrote:
> As it has been said and written many times already, in reality this is
> not broken by design at all and in fact it is the only successful
> strategy that has been deployed by other distros - it's what is being
> called merged-usr-via-moves-and-symlink-farms that is broken. We can
> say this with certainty because both approaches have been tried, so
> there's actual real-world data to look at. Just go look at the absolute
> mess that Suse got themselves into by following that solution - a 10-
> years-long massive half-done-never-finished headache that took an
> inordinate amount of work to back out of, and move to the actual
> working solution that everybody else are using - merged-usr-via-
> aliased-dirs. On the other hand Fedora/RHEL had a smooth and simple
> transition using merged-usr-via-aliased-dirs, and that was the end of
> it.

Yes, a single (a couple!?) data point(s) of a strategy used in another
unrelated distribution, with completely different packaging stacks and
ecosystems, which was done very poorly, has been presented repeatedly.
I'm not sure why that has much value TBH.

The above seems to also be confusing how and if a design has been
deployed, with its inherent (short and long term) properties. A badly
performed *deployment* for a better design does not make its properties
bad, in the same way that *deploying* a flawed design faster does not
make its properties better…

What I've also said multiple times, is that
merged-usr-via-moves-and-symlink-farms could have been implemented in
a fully automated way, by debhelper, w/o requiring any maintainer scripts,
all with full cooperation and managed by dpkg, with .debs shipping
actual tracked pathnames, if it had not been for the mess required
by merged-usr-via-aliased-dirs. :/

> Dpkg has some very minor bugs that rpm/dnf/yum/zypper/whatever do not
> suffer from. So what? It is perfectly normal as it's software and all
> softwares have bugs. They could be fixed, worked around, or ignored,
> like all other bugs.

If by "very minor bugs" you mean that f.ex.:

 * dpkg, dpkg-divert, or update-alternatives are unable to detect file
   conflicts and thus might allow silent overwrites of random stuff on
   disk,
 * when moving files across packages and across aliased directories,
   these pathnames might end up disappearing depending on the unpack
   order,
 * dpkg-deb -x on the root directory (yes, people use this to recover
   systems) with any .deb that contains files on real directories under
   «/», will replace the symlinked directories with real ones,

then, yes, I guess "very minor" indeed. But then I completely object
to this being classified as bugs in dpkg, as this has been shoved in
disregarding that dpkg does *not* support this, and it would require
new *features* to be implemented, so this "transition" is founded on
assuming features that do not exist, or completely going behind
dpkg's back, which sounds great I guess…

The problem in general is that this layout introduces unreliability
and silently induced breakage stemming from this flawed filesystem
layout, which is going to affect the people that are going to benefit
the less from its properties, and are the less experience to deal with
it.

I've tried to update the <https://wiki.debian.org/Teams/Dpkg/MergedUsr>
with more explicit information, in case some people might have missed
that from previous instances of this discussion, and added an initial
table of properties for both proposals, to avoid cluttering and repeating
it on the list, and to ease updating it.




We do actually have experience with "an aliased" layout from symlinked
/usr/share/doc/ directories, where those are for optional/removable parts
of the filesystem, and the symlinks are even known and managed by dpkg.
And those have been a major and constant source of packaging bugs.

And here we are getting the project installing by default systems that
are fighting the packaging system and going on its back, to enable a
filesystem design layout mostly experienced admins will benefit from
in very special deployment conditions, where final users can very
easily suffer from its introduced unreliability (from 3rd-party repos
or locally built packages, etc, f.ex.).

Because the above has been brought up before and the proponents are well
aware of these, I'm afraid at this point the only thing that comes to
mind is negligence, TBH. :/

But *shrug*, have at it, I'm tired of the continued and complete
disregard of the unreliability issues and subversion of the packaging
system, which are supposed to be pillars of our project, every single
time. I just replied so that people that might not want to be forced
into this stuff know that there's going to be a way out.

Regards,
Guillem

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Polyna-Maude Racicot-Summerside]

Hi,

On 2021-07-18 7:21 p.m., Russ Allbery wrote:
> Polyna-Maude Racicot-Summerside  writes:
> 
>> Here's my actual config (with 2TB) and yes I have a separate /home
> 
>> What is tmpfs and why is it set to 3.2 GB ?
> 
> tmpfs is a RAM-backed temporary file system that is automatically used for
> paths like /run and /dev/shm that are supposed to be cleared on each
> reboot and hold only small files (or memory references, in the case of
> /dev/shm).
> 
> I see that you have your system configured to store /tmp on your disk.
> This is generally not recommended these days.  Storing /tmp in tmpfs is
> much faster for some applications and automatically achieves the desired
> and standard /tmp behavior of clearing it on reboot.  About the only
> reason not to use tmpfs is if you have a very memory-constrained system
> and don't want to use any member at all for memory-backed file systems.
> 
I had the belief that some software used /tmp for temporary file that
may grow many GB (example DVD creation).

I have 32 GB

>> And /dev have 16G free ? Where does this come from...
> 
> The size of the udev file system is essentially meaningless.
> 
>> I'm wasting some space with /tmp !
> 
> I agree with the other feedback that you are overpartitioning your disk.
> I used to do this back when I was first learning UNIX in the 1990s because
> it seems like a good idea and it does isolate one part of the system from
> another if it uses an excessive amount of space.  But what I found in
> practice, and what almost everyone who does this eventually finds in
> practice, is that this much partitioning drastically reduces the long-term
> flexibility of the system.  It requires you predict in advance what parts
> of the system will grow, and when you guess wrong, you end up with
> symlinks trying to move directories from a partition with no free space to
> another partition with free space, with all the complexity and breakage
> that can cause.
> 
> There are some technical reasons to separate /boot if you are using a file
> system for other partitions that isn't suitable for early boot (or if
> you're using cryptsetup or other file system layers).  /boot/efi is always
> a separate partition because of how it works.  Apart from those two
> special cases, the only reason to put something on a separate file system
> is if you have a clear and compelling reason why you expect a given file
> system to run out of space and you want to ensure that it cannot take
> space from other parts of the system.
> 
> This can be a good justification for putting /home on a separate partition
> *if* you are running a multi-user system.  But otherwise, separating out
> things like /var or /usr/local or /opt or /srv is more likely to cause you
> long-term headaches than it is to do anything useful.
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Andy Smith]

Hi,

On Sun, Jul 18, 2021 at 05:54:33PM -0400, Polyna-Maude Racicot-Summerside wrote:
> On 2021-07-18 5:07 p.m., Andy Smith wrote:
> > I recommend understanding the issue before putting forth an opinion.
> > 
> Maybe I shall correct what I said as it may be misunderstood.

It's unclear to me why you've taken my reply to your mail on
debian-user, and instead sent it to me privately and also to
debian-devel.

As neither of us are Debian Developers and you don't seem to have
done much research regarding merged-/usr, I don't feel it is
on-topic for me to continue that conversation with you on
debian-devel.

I recommend doing some more reading of these threads and the
relevant wiki pages and if things are still unclear then asking
user-level questions only on debian-user.

Thanks,
Andy

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Russ Allbery]

Russ Allbery  writes:

> I see that you have your system configured to store /tmp on your disk.
> This is generally not recommended these days.  Storing /tmp in tmpfs is
> much faster for some applications and automatically achieves the desired
> and standard /tmp behavior of clearing it on reboot.  About the only
> reason not to use tmpfs is if you have a very memory-constrained system
> and don't want to use any member at all for memory-backed file systems.

Argh, that should have been "and don't want to use any *memory* at all for
memory-backed file systems."

Apologies for the additional message, but that word substitution was
sufficiently confusing that I'm not sure the intended meaning was clear.

-- 
Russ Allbery (r...@debian.org)  

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Russ Allbery]

Svante Signell  writes:

> Again, everybody is just hiding, I wonder from who, the big wolf??  Who
> is hen? Anybody having the courage to reply to this list about this
> issue, not only workarounds/diversions?

I'm not discussing the issue on the list because I think the current
direction in which Debian is heading seems reasonable and forward progress
is being made, so there doesn't seem to be anything to argue about or any
point in doing so.

The folks who have been upset about this direction for years are still
upset and I'm sorry that they're still upset and that we haven't found
some approach that makes everyone happy.  But so far as I can tell, there
have been no new substantive arguments and no changes in direction, so
there doesn't seem to be anything new to reply about, particularly given
that I'm not involved in the implementation and therefore am not involved
in analyzing any of the technical concerns they raise.

"Courage" seems to me like an odd label to put on any of this.

-- 
Russ Allbery (r...@debian.org)  

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Russ Allbery]

Polyna-Maude Racicot-Summerside  writes:

> Here's my actual config (with 2TB) and yes I have a separate /home

> What is tmpfs and why is it set to 3.2 GB ?

tmpfs is a RAM-backed temporary file system that is automatically used for
paths like /run and /dev/shm that are supposed to be cleared on each
reboot and hold only small files (or memory references, in the case of
/dev/shm).

I see that you have your system configured to store /tmp on your disk.
This is generally not recommended these days.  Storing /tmp in tmpfs is
much faster for some applications and automatically achieves the desired
and standard /tmp behavior of clearing it on reboot.  About the only
reason not to use tmpfs is if you have a very memory-constrained system
and don't want to use any member at all for memory-backed file systems.

> And /dev have 16G free ? Where does this come from...

The size of the udev file system is essentially meaningless.

> I'm wasting some space with /tmp !

I agree with the other feedback that you are overpartitioning your disk.
I used to do this back when I was first learning UNIX in the 1990s because
it seems like a good idea and it does isolate one part of the system from
another if it uses an excessive amount of space.  But what I found in
practice, and what almost everyone who does this eventually finds in
practice, is that this much partitioning drastically reduces the long-term
flexibility of the system.  It requires you predict in advance what parts
of the system will grow, and when you guess wrong, you end up with
symlinks trying to move directories from a partition with no free space to
another partition with free space, with all the complexity and breakage
that can cause.

There are some technical reasons to separate /boot if you are using a file
system for other partitions that isn't suitable for early boot (or if
you're using cryptsetup or other file system layers).  /boot/efi is always
a separate partition because of how it works.  Apart from those two
special cases, the only reason to put something on a separate file system
is if you have a clear and compelling reason why you expect a given file
system to run out of space and you want to ensure that it cannot take
space from other parts of the system.

This can be a good justification for putting /home on a separate partition
*if* you are running a multi-user system.  But otherwise, separating out
things like /var or /usr/local or /opt or /srv is more likely to cause you
long-term headaches than it is to do anything useful.

-- 
Russ Allbery (r...@debian.org)  

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Polyna-Maude Racicot-Summerside]

Hi,

On 2021-07-18 6:17 p.m., Marco d'Itri wrote:
> On Jul 19, Polyna-Maude Racicot-Summerside  wrote:
> 
>> So if I get it right...
> Except for /boot/, which may be required for technical reasons, there 
> is no need to further partition your file system unless you actually 
> have reasons to do it.
> 
>> One partiton for /boot
>> One partition for /usr
>> One partition for /usr/local (if you feel like it)
>> One / partiton that will contain not much stuff other than config files ?
>> One partition for /var (if you feel)
>> One partition for /opt, /srv ...
>> One partition for /tmp
> If you are aiming for overcomplexity then I think that you forgot /home.
> 
>> The root partition can be small as 16 Gb as it won't contain much ?
> If you create a partition for everything else as described here then 
> / will only contain /etc and /root, so even 1 GB will be enough.
> But again, I do not really recommend this.
> 
> I do not recommend to partition general purpose systems with less than 
> a few hundreds of GBs of allocated disk space.
> 

Here's my actual config (with 2TB) and yes I have a separate /home

What is tmpfs and why is it set to 3.2 GB ?
And /dev have 16G free ? Where does this come from...
I'm wasting some space with /tmp !

Filesystem  Size  Used Avail Use% Mounted on
udev 16G 0   16G   0% /dev
tmpfs   3.2G  2.1M  3.2G   1% /run
/dev/sda3   184G   70G  105G  40% /
tmpfs16G  163M   16G   2% /dev/shm
tmpfs   5.0M  4.0K  5.0M   1% /run/lock
/dev/sda5   262G   50G  199G  21% /var
/dev/sda4   175G   86M  166G   1% /tmp
/dev/sda888G   60M   83G   1% /usr/local
/dev/sda792G  3.6G   84G   5% /opt
/dev/sda10   92G   60M   87G   1% /srv
/dev/sda1   487M  3.3M  483M   1% /boot/efi
/dev/sda11  733G  649G   47G  94% /home
tmpfs   3.2G   84K  3.2G   1% /run/user/118
tmpfs   3.2G  124K  3.2G   1% /run/user/1000


-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Svante Signell]

On Sun, 2021-07-18 at 20:58 +0200, Svante Signell wrote:
> On Wed, 2021-07-14 at 23:40 +0200, Guillem Jover wrote:
> > On Wed, 2021-07-14 at 19:54:56 +, Thorsten Glaser wrote:
> > > Sean Whitton dixit:
> > > > * #978636 move to merged-usr-only?
> > > > 
> > > >  We were asked to decide whether or not Debian 'bookworm'
> > > > should
> > > >  continue to support systems which are not using the merged-usr
> > > >  filesystem layout.  We decided that support should not
> > > > continue
> > > > beyond Debian 'bullseye'.
> > > 
> > > What? WHAT? ＷＨＡＴ？
> > > 
> > > >  The decision is captured here:
> > > >  <https://bugs.debian.org/978636#178>
> > > 
> > > No reason provided either. This stinks. I’m v̲e̲r̲y̲
> > > disappointed.
> > > Debian is becoming untenable. Years ago, I had hoped it won’t.
> > 
> > I've been meaning to send a note about this for some time now, but
> > as I feel it keeps getting ignored, it always seems a bit
> > pointless.
> > 
> > But in any case, given that merged-usr-via-aliased-dirs is not
> > really
> > supported by dpkg anyway, it is broken by design [B], I have no
> > intention whatsoever to break any of my systems with such layout
> > going forward, I'm thus planning to spend any necessary volunteer
> > time implementing any fix, workaround or solution required to avoid
> > having to use it, in detriment of other Debian volunteer time. I
> > alreadystarted some time ago with dpkg-fsys-usrunmess(8), present
> > already inthe upcoming bullseye release.
> > 
> [B] 
> https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Does_dpkg_support_merged-.2Fusr-via-aliased-dirs.3F
> 
> Since the dpkg developer and maintainer Guillem considers merged /usr
> broken by design, maybe Debian should consider to use some other
> package management software for the peace of mind for people involved
> in the project? Maybe guix could be usable?

Again, everybody is just hiding, I wonder from who, the big wolf??
Who is hen? Anybody having the courage to reply to this list about this
issue, not only workarounds/diversions?

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Marco d'Itri]

On Jul 19, Polyna-Maude Racicot-Summerside  wrote:

> So if I get it right...
Except for /boot/, which may be required for technical reasons, there 
is no need to further partition your file system unless you actually 
have reasons to do it.

> One partiton for /boot
> One partition for /usr
> One partition for /usr/local (if you feel like it)
> One / partiton that will contain not much stuff other than config files ?
> One partition for /var (if you feel)
> One partition for /opt, /srv ...
> One partition for /tmp
If you are aiming for overcomplexity then I think that you forgot /home.

> The root partition can be small as 16 Gb as it won't contain much ?
If you create a partition for everything else as described here then 
/ will only contain /etc and /root, so even 1 GB will be enough.
But again, I do not really recommend this.

I do not recommend to partition general purpose systems with less than 
a few hundreds of GBs of allocated disk space.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Polyna-Maude Racicot-Summerside]

Hello (Hi) !

On 2021-07-18 5:07 p.m., Andy Smith wrote:
> Hello,
> 
> I think all of this is quite clearly explained in:
> 
> https://salsa.debian.org/md/usrmerge/raw/master/debian/README.Debian
> 
> which is linked from:
> 
> https://wiki.debian.org/UsrMerge
> 
> If you think it's not then you should probably raise a bug against
> the usrmerge package with your suggested edits/clarifications.
>
I've read the link above plus the link to
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

So if I get it right...

One partiton for /boot
One partition for /usr
One partition for /usr/local (if you feel like it)
One / partiton that will contain not much stuff other than config files ?
One partition for /var (if you feel)
One partition for /opt, /srv ...
One partition for /tmp

The root partition can be small as 16 Gb as it won't contain much ?

Am I getting this right ?

Here's my actual partition table (2TB HD)

udev 16G 0   16G   0% /dev
tmpfs   3.2G  2.1M  3.2G   1% /run
/dev/sda3   184G   70G  105G  40% /
tmpfs16G  163M   16G   2% /dev/shm
tmpfs   5.0M  4.0K  5.0M   1% /run/lock
/dev/sda5   262G   50G  199G  21% /var
/dev/sda4   175G   86M  166G   1% /tmp
/dev/sda888G   60M   83G   1% /usr/local
/dev/sda792G  3.6G   84G   5% /opt
/dev/sda10   92G   60M   87G   1% /srv
/dev/sda1   487M  3.3M  483M   1% /boot/efi
/dev/sda11  733G  649G   47G  94% /home

I currently have a 70G usage of the root partition.
Running Buster.

> Andy
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Polyna-Maude Racicot-Summerside]

Hi,

On 2021-07-18 5:07 p.m., Andy Smith wrote:
> Hello,
> 
> On Sun, Jul 18, 2021 at 04:31:11PM -0400, Polyna-Maude Racicot-Summerside 
> wrote:
>> My personal opinion is that Debian is going into a mostly "we got the
>> best idea in the world but forgot that not everyone implement things the
>> same way".
> 
> I recommend understanding the issue before putting forth an opinion.
> 
Maybe I shall correct what I said as it may be misunderstood.

Without regard to this specific issue, I seem to have noticed that the
Debian project has made some change in good faith, based on some
technological conception of what is the best. But in the end, most user
seem not to need those change and be a source of problem for most of them.

I've had hell of a mess to understand the change to SystemD.

Not so long ago I even learned that it caused a fork for a Debian
derivative called Devuan.

For me it was a huge departure from the KISS philosophy and I feel that
this "usrmerge" is going the same way.

I will take time to review what you have gave me as link and see what
will be my opinion after this.

>> I currently have a different partition for my /usr and this has been the
>> case since the end of 1990s when I started on Linux. Maybe I'm wrong but
>> I like it this way.
>>
>> Will the merge-usr cause myself problem ?
> 
> No. Not as long as you use an initramfs created by any of the
> supported Debian tools like initramfs-tools or dracut, which you
> will do unless you have gone out of your way to do something
> different.
> 
I've did many Debian install, using the standard installation software,
creating those partition from the "expert" choice of install mode. And
never had problem, I believe that the initramfs tools must be doing
their job.

> And regardless of merged-/usr, /usr on separate partition has not
> been supported in Debian without an initramfs since the stretch
> release in 2017.
> 
I've used Stretch with a separate /usr without much problem, as said above.

> I think all of this is quite clearly explained in:
> 
> https://salsa.debian.org/md/usrmerge/raw/master/debian/README.Debian
> 
> which is linked from:
> 
> https://wiki.debian.org/UsrMerge
> 
> If you think it's not then you should probably raise a bug against
> the usrmerge package with your suggested edits/clarifications.
> 
> Andy
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Polyna-Maude Racicot-Summerside]

Hi,

On 2021-07-18 5:31 p.m., Svante Signell wrote:
> Hi, is it OK to forward your mail to debian-devel. I don't think
> mailing to debian-user will have any effect on this issue?
>  
Sure ! Honestly it's my mistake to have sent it to debian-user.
I get everything in one mailbox. I need to have this sorted out and use
one mailbox for each mailing list.

Thanks

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Helmut Grohne]

On Fri, Jul 16, 2021 at 01:15:37PM +0200, Magissia wrote:
> In this case, this page should be updated to reflect the fact it is not
> broken.
> 
> https://wiki.debian.org/Teams/Dpkg/MergedUsr

Logic does not quite work that way. Just because we selected that way of
doing things doesn't imply it would not be broken. Arguably, if it
wasn't broken, there would not have been a need to defer the decision to
the CTTE as there would have been consensus on choosing the non-broken
way already. The CTTE was tasked to choose the less broken one of two
broken options and it did.

>From a dpkg pov, the aliasing technique continues to be broken and the
solution continues to manifest as unintuitive behaviour and related
issues. Calling that broken sounds fair to me.

The thing that makes me a little grumpy about this is that the
proponents of the /usr merge continue stuffing ever more fingers into
their ears when faced with problems. I for one wouldn't care as much if
the /usr merge wasn't that much of a time sink to me. For instance, I
happened to be one of the first affected users of dpkg-shlibdeps ceasing
to work. I'd really like to ignore the whole mess and leave it to
others (and that includes not opposing it).

I also note that there is a subtle difference between those who disagree
with the /usr merge and those that disagree with its implementation
strategy. The former ones seems like a very small minority to me. As a
result, reiterating the "why" is kinda pointless as there already seems
to be consensus on that front. As for the how, there seems to be rough
consensus that all implementation strategies are broken one way or
another. We just get to pick the least painful one and deferred the
choice to the CTTE.

Maybe someone could fix #858331 et al and we can move on?

Helmut

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Svante Signell]

On Wed, 2021-07-14 at 23:40 +0200, Guillem Jover wrote:
> On Wed, 2021-07-14 at 19:54:56 +, Thorsten Glaser wrote:
> > Sean Whitton dixit:
> > > * #978636 move to merged-usr-only?
> > > 
> > >  We were asked to decide whether or not Debian 'bookworm' should
> > >  continue to support systems which are not using the merged-usr
> > >  filesystem layout.  We decided that support should not continue
> > > beyond Debian 'bullseye'.
> > 
> > What? WHAT? ＷＨＡＴ？
> > 
> > >  The decision is captured here:
> > >  <https://bugs.debian.org/978636#178>
> > 
> > No reason provided either. This stinks. I’m v̲e̲r̲y̲ disappointed.
> > Debian is becoming untenable. Years ago, I had hoped it won’t.
> 
> I've been meaning to send a note about this for some time now, but
> as I feel it keeps getting ignored, it always seems a bit pointless.
> 
> But in any case, given that merged-usr-via-aliased-dirs is not really
> supported by dpkg anyway, it is broken by design [B], I have no
> intention whatsoever to break any of my systems with such layout
> going forward, I'm thus planning to spend any necessary volunteer
> time implementing any fix, workaround or solution required to avoid
> having to use it, in detriment of other Debian volunteer time. I
> alreadystarted some time ago with dpkg-fsys-usrunmess(8), present
> already inthe upcoming bullseye release.
> 
[B] 
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Does_dpkg_support_merged-.2Fusr-via-aliased-dirs.3F
>

Since the dpkg developer and maintainer Guillem considers merged /usr
broken by design, maybe Debian should consider to use some other
package management software for the peace of mind for people involved
in the project? Maybe guix could be usable?

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Andrey Rahmatullin]

On Sun, Jul 18, 2021 at 10:11:22PM +0500, Andrey Rahmatullin wrote:
> While, AFAIK, it's indeed only Debian Policy stopping you from not
> shipping /usr/share/doc/*/copyright, and that and common sense stopping
> you from not shipping /usr/share/doc/*/changelog, that's just yet another
> case of something broken that we probably are not required to support.
... even though these files really belong with other dpkg metadata in
/var/lib/dpkg...

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Andrey Rahmatullin]

On Sun, Jul 18, 2021 at 04:50:49PM +, Stephan Verbücheln wrote:
> Thank you for the explanation. I think it covers most use cases.
> However, it does not cover packages that do not actually install
> programs but only perform changes to /etc or install something to /opt,
> is that correct?
While, AFAIK, it's indeed only Debian Policy stopping you from not
shipping /usr/share/doc/*/copyright, and that and common sense stopping
you from not shipping /usr/share/doc/*/changelog, that's just yet another
case of something broken that we probably are not required to support.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Stephan Verbücheln]

Thank you for the explanation. I think it covers most use cases.
However, it does not cover packages that do not actually install
programs but only perform changes to /etc or install something to /opt,
is that correct?

Regards

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Marco d'Itri]

On Jul 18, Stephan Verbücheln  wrote:

> On Sun, 2021-07-18 at 11:13 +0200, Marco d'Itri wrote:
> > I link /var/lib/dpkg/ to somewhere in /usr/, and I think that this is
> > 
> What? No matter whether we merge “/bin” or not, “/usr” should stay
> read-only.
The dpkg database IS read-only as long as you are not installing or 
removing packages, which you cannot do anyway if /usr is read-only.
In other words, the read-only state of the dpkg database is tightly 
coupled with the read-only state of /usr.

The only corner case which would require some more thinking is how to 
handle changing diversions of files in /etc in the systems with the 
read-only /usr, and for the time being "don't do that" could be 
a totally valid solution.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Andrey Rahmatullin]

On Sun, Jul 18, 2021 at 11:09:49AM +, Stephan Verbücheln wrote:
> On Sun, 2021-07-18 at 11:13 +0200, Marco d'Itri wrote:
> > I link /var/lib/dpkg/ to somewhere in /usr/, and I think that this is
> > 
> 
> What? No matter whether we merge “/bin” or not, “/usr” should stay
> read-only.
On Debian /usr is changed only when /var/lib/dpkg is changed (ideally).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Stephan Verbücheln]

On Sun, 2021-07-18 at 11:13 +0200, Marco d'Itri wrote:
> I link /var/lib/dpkg/ to somewhere in /usr/, and I think that this is
> 

What? No matter whether we merge “/bin” or not, “/usr” should stay
read-only.

Regards

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Bastian Blank]

On Sun, Jul 18, 2021 at 11:13:37AM +0200, Marco d'Itri wrote:
> On Jul 18, Simon McVittie  wrote:
> > If a machine's /usr is not in sync with its /etc and /var, then it is likely
> > to work incorrectly: at a minimum, asking dpkg which packages and versions
> But in my experience (with shared-/usr containers) this works great as 
> long as everything is aligned to the same major Debian release.

So we can just merge it and make it break even less likely?

Bastian

-- 
A princess should not be afraid -- not with a brave knight to protect her.
-- McCoy, "Shore Leave", stardate 3025.3

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Marco d'Itri]

On Jul 18, Simon McVittie  wrote:

> If a machine's /usr is not in sync with its /etc and /var, then it is likely
> to work incorrectly: at a minimum, asking dpkg which packages and versions
But in my experience (with shared-/usr containers) this works great as 
long as everything is aligned to the same major Debian release.

> are installed will give you an answer that does not match what is actually
> in /usr.
I link /var/lib/dpkg/ to somewhere in /usr/, and I think that this is 
something that we should do anyway.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: merged /usr considered harmful

[Geert Stappers]

Summary: let go, let go

On Sat, Jul 17, 2021 at 09:13:57PM +, Thorsten Glaser wrote:
> 
> And no, I’m not going to embrace every unnecessary change thrown my way.

None of us does embraces every unnecessary change.
We all choose our battles wisely.


> No; usrmerge is broken from the PoV of Debian’s package manager.
> Running usrmerge breaks assumptions done by dpkg; you can probably
> do it with RPM or something, but it’s not supported with dpkg.

Hence a change.


Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Simon McVittie]

On Sat, 17 Jul 2021 at 20:34:41 +, Johannes Drexl wrote:
> /usr is allowed to be not only on a separate partition, but even on a
> network device

This has been discussed at considerable length before, but I'll try to
recap:

A separate or network-mounted /usr is possible in Debian, whether
merged-/usr is used or not, but only if /usr is already mounted
by the time the system hands over from the initramfs (usually generated by
initramfs-tools, or sometimes dracut or another alternative) to the main
system (which starts systemd, sysvinit or some other init system as the
main pid 1 and proceeds from there). Merged /usr is actually better for
this configuration than unmerged /usr in some ways: it lets you share
*all* the non-modifiable files between machines, not just the ones that
are in /usr (as opposed to /lib, /bin, /sbin).

This is not a new requirement: Debian >= 9 (2017) officially did not support
mounting /usr halfway through the main system boot process. Older Debian
releases aimed to support /usr being mounted during boot (for example
during the rcS sequence in sysv-rc) but it frequently didn't actually
work in practice, particularly if combined with network mounts.

The reason why mounting /usr during main-system boot is no longer
supported is that it often didn't work. A major reason why it often didn't
work is that depending on how the system is configured, mounting /usr can
require networking; but bringing up networking can require arbitrarily
many programs and libraries (networking infrastructure like ifupdown or
NetworkManager often has either a plugin architecture, or an arbitrary
hooks mechanism that executes programs of the sysadmin's choice that
will often have dependencies in /usr, or both).

Similarly, udevd needs to run early in the main system boot to bring up
/dev, but udev rules can run arbitrary programs, some of them in /usr;
and for the main system, those programs often need data from /usr/share.

More generally, if we took every library and every program that could
conceivably be a dependency of /usr and moved them from /usr into the
root filesystem, then the root filesystem would become increasingly large
over time, negating any benefit that you hoped to gain by mounting /usr
separately. Over time, this approach would tend towards the layout that
the Debian Hurd port briefly tried to use, which was the opposite of
merged-/usr (you could call it "merged rootfs"), with /usr as either a
symlink to /, or containing only symlinks to /lib, /bin and so on.

Instead, we require everything that is needed in *your* configuration
(not necessarily in *anyone's* configuration, just yours!) to be part
of the initramfs, which is generated per-machine.

Effectively, the requirement to mount /usr before pivoting from initramfs
to main system means that instead of a small rootfs (which can be used for
recovery) and a larger /usr, we have a small initramfs (which can be used
for recovery) and a large main system.

One key advantage of this is that decisions about what to include in
the rootfs (of non-merged-/usr systems) have to be made globally for all
of Debian, but decisions about what to include in the initramfs can be
made per-machine, allowing some otherwise impossible situations to be
resolved. If your /usr is mounted via NFS, but bringing up my network
requires /usr (perhaps for a VPN), in the old model with a small rootfs
and a larger /usr it was impossible for us both to have what we needed:
we could not bring up networking both before /usr (as you would have
needed) and after /usr (as I would have needed).

> /usr is allowed to be [...] on a network device shared by other machines

The FHS may allow this, but it has significant practical problems,
unrelated to merged-/usr, on machines that receive security/stable updates
(which I would hope by now should mean all machines). Updates to Debian
packages can touch both mutable per-machine files (/etc, /var) and
immutable/shareable per-(package,version) files (/usr, /lib*, /bin, /sbin).
If a machine's /usr is not in sync with its /etc and /var, then it is likely
to work incorrectly: at a minimum, asking dpkg which packages and versions
are installed will give you an answer that does not match what is actually
in /usr.

On non-merged-/usr systems, the machine's /usr and {/lib*,/bin,/sbin}
must also be kept in sync: for example, there is no guarantee that
/usr/bin/dbus-daemon (in /usr) will work correctly with a mismatched
version of /lib/x86_64-linux-gnu/libdbus-1.so.3 (on the rootfs of a
non-merged-/usr system). On merged-/usr systems, it is impossible for
those directories to become out-of-sync, so this particular requirement
becomes trivial to achieve.

A more robust approach to sharing /usr between machines (or containers)
might be to give each machine (or container) its own private /usr or even
its own private root filesystem, and then carry out file- or block-level
ded

Re: merged /usr considered harmful

[Thorsten Glaser]

Johannes Drexl dixit:

>embrace getting rid of /sbin and /bin. FHS 3.0 explicitely states that
>/usr is allowed to be not only on a separate partition, but even on a
>network device shared by other machines:

This hasn’t been true on Debian for a while (partially due to the
systemd/usrmerge proponents, partially due to the difficulty of
deciding what needs to be present). You have had to either ensure
/usr is mounted by an initrd or it’s not on a separare filesystem
for a while, already (and that was fine with me, it’s the usrmerge
crap that totally pointlessly breaks things).

And no, I’m not going to embrace every unnecessary change thrown my way.


Magissia dixit:

>In this case, this page should be updated to reflect the fact it is not
>broken.

No; usrmerge is broken from the PoV of Debian’s package manager.
Running usrmerge breaks assumptions done by dpkg; you can probably
do it with RPM or something, but it’s not supported with dpkg.

bye,
//mirabilos
-- 
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Johannes Drexl]

Am Freitag, dem 16.07.2021 um 10:09 +0200 schrieb Thomas Goirand:
> Merging binaries in /usr and getting rid of /bin and /sbin, at the
> end,
> WILL be an improvement. Debian cannot be the last distro not doing
> the
> move, I hope you understand that.
> 
> Also, I'm having a hard time understanding why moving binaries around
> should just break any system

Well, I'm only an interested SysOp here, but I share his reluctance to
embrace getting rid of /sbin and /bin. FHS 3.0 explicitely states that
/usr is allowed to be not only on a separate partition, but even on a
network device shared by other machines:

Quoting FHS 3.0, chapter 4.1, Purpose of /usr: 
'/usr is the second major section of the filesystem. /usr is shareable,
read-only data. That means that /usr should be shareable between
various FHS-compliant hosts and must not be written to.'

On the other hand /bin and /sbin need to be on the root partition in
case mounting of other partitions doesn't work (as in "no network
available").

Quoting FHS 3.0, chapter 3.16.1, Purpose of /sbin:
'/sbin contains binaries essential for booting, restoring, recovering,
and/or repairing the system in addition to the binaries in /bin.
Programs executed after /usr is known to be mounted (when there are no
problems) are generally placed into /usr/sbin.'

So yes, with getting rid of /bin and /sbin you break the systems
emergency resilience and deviate from a known and not really that old
standard. I'm not quite sure how this is an improvement - rather I'm
curious how one could perceive this as such. For all I've seen in my
time as a SysOp, I'd rather have my emergency tools in /sbin and /bin
than booting a live system every time a server has broken mounts.

That all said, I'm not fully against the change, I just don't see the
benefit but instead quite a lot of problems down the road.

BR
Jo


signature.asc
Description: This is a digitally signed message part

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Magissia]

In this case, this page should be updated to reflect the fact it is not
broken.

https://wiki.debian.org/Teams/Dpkg/MergedUsr

Nol'

Le jeudi 15 juillet 2021 à 10:13 +0100, Luca Boccassi a écrit :
> On Wed, 2021-07-14 at 23:40 +0200, Guillem Jover wrote:
> > On Wed, 2021-07-14 at 19:54:56 +, Thorsten Glaser wrote:
> > > Sean Whitton dixit:
> > > > * #978636 move to merged-usr-only?
> > > > 
> > > >  We were asked to decide whether or not Debian 'bookworm'
> > > > should
> > > >  continue to support systems which are not using the merged-usr
> > > >  filesystem layout.  We decided that support should not
> > > > continue beyond
> > > >  Debian 'bullseye'.
> > > 
> > > What? WHAT? ＷＨＡＴ？
> > > 
> > > >  The decision is captured here:
> > > >  <https://bugs.debian.org/978636#178>
> > > 
> > > No reason provided either. This stinks. I’m v̲e̲r̲y̲
> > > disappointed.
> > > Debian is becoming untenable. Years ago, I had hoped it won’t.
> > 
> > I've been meaning to send a note about this for some time now, but
> > as I feel it keeps getting ignored, it always seems a bit
> > pointless.
> > 
> > But in any case, given that merged-usr-via-aliased-dirs is not
> > really
> > supported by dpkg anyway, it is broken by design [B], I have no
> > intention whatsoever to break any of my systems with such layout
> > going
> > forward, I'm thus planning to spend any necessary volunteer time
> > implementing any fix, workaround or solution required to avoid
> > having
> > to use it, in detriment of other Debian volunteer time. I already
> > started some time ago with dpkg-fsys-usrunmess(8), present already
> > in
> > the upcoming bullseye release.
> > 
> > [B] <
> > https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Does_dpkg_support_merged-.2Fusr-via-aliased-dirs.3F
> > >
> > 
> > Thanks,
> > Guillem
> 
> Hi,
> 
> As it has been said and written many times already, in reality this
> is
> not broken by design at all and in fact it is the only successful
> strategy that has been deployed by other distros - it's what is being
> called merged-usr-via-moves-and-symlink-farms that is broken. We can
> say this with certainty because both approaches have been tried, so
> there's actual real-world data to look at. Just go look at the
> absolute
> mess that Suse got themselves into by following that solution - a 10-
> years-long massive half-done-never-finished headache that took an
> inordinate amount of work to back out of, and move to the actual
> working solution that everybody else are using - merged-usr-via-
> aliased-dirs. On the other hand Fedora/RHEL had a smooth and simple
> transition using merged-usr-via-aliased-dirs, and that was the end of
> it.
> 
> Dpkg has some very minor bugs that rpm/dnf/yum/zypper/whatever do not
> suffer from. So what? It is perfectly normal as it's software and all
> softwares have bugs. They could be fixed, worked around, or ignored,
> like all other bugs.
> 

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Thomas Goirand]

On 7/16/21 10:09 AM, Thomas Goirand wrote:
> On 7/14/21 9:54 PM, Thorsten Glaser wrote:
>> Sean Whitton dixit:
>>
>>> * #978636 move to merged-usr-only?
>>>
>>>  We were asked to decide whether or not Debian 'bookworm' should
>>>  continue to support systems which are not using the merged-usr
>>>  filesystem layout.  We decided that support should not continue beyond
>>>  Debian 'bullseye'.
>>
>> What? WHAT? ＷＨＡＴ？
>>
>>>  The decision is captured here:
>>>  <https://bugs.debian.org/978636#178>
>>
>> No reason provided either. This stinks. I’m v̲e̲r̲y̲ disappointed.
>> Debian is becoming untenable. Years ago, I had hoped it won’t.
>>
>> bye,
>> //mirabilos
> 
> Hi Thorsten,
> 
> Sent privately, I hope you don't mind.

It was sent to the list, never mind, there's nothing private here, just
a call to be more constructive...

Cheers,

Thomas Goirand (zigo)

Re: merged /usr considered harmful

[Pierre-Elliott Bécue]

Thorsten Glaser  writes:
>>But in any case, given that merged-usr-via-aliased-dirs is not really
>>supported by dpkg anyway, it is broken by design [B], I have no
>
> Time for another GR? Leaving Debian behind?

Threats of leaving are not fine and are just making any discussion
pointless.

I refuse (and I recommend no one accepts) to enter debate with someone
putting their involvment in the balance as a way to force their opinion
in.

--
PEB


signature.asc
Description: PGP signature

Re: merged /usr considered harmful

[The Wanderer]

On 2021-07-16 at 03:18, Marc Haber wrote:

> On Fri, 16 Jul 2021 01:44:54 + (UTC), Thorsten Glaser
>  wrote:
>
>>Marc Haber dixit:
>>
>>>think we can afford an additional time sink at the moment. Please, get
>>
>>While that’s true…
> 
> You conveniently snipped the "I don't" which turns your quote into the
> opposite that I wanted to say.

No, he didn't; he reordered the quoted lines (moving this one ahead of
the rest), so that he could put this one line of his reply where it
would make the most sense relative to the rest of his reply, without
also having to adjust the within-each-line quoting etc.. The "I don't"
is in the first line which you yourself didn't quote.

The result was slightly confusing to me at first glance, but I figured
it out within a minute.

If you'd chosen to chide him for reordering lines in a way which
(presumably inadvertently) produced an initially-misleading result, that
would be one thing, but I don't think it's appropriate to accuse him of
snipping out context when he didn't do so.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Thomas Goirand]

On 7/14/21 9:54 PM, Thorsten Glaser wrote:
> Sean Whitton dixit:
> 
>> * #978636 move to merged-usr-only?
>>
>>  We were asked to decide whether or not Debian 'bookworm' should
>>  continue to support systems which are not using the merged-usr
>>  filesystem layout.  We decided that support should not continue beyond
>>  Debian 'bullseye'.
> 
> What? WHAT? ＷＨＡＴ？
> 
>>  The decision is captured here:
>>  <https://bugs.debian.org/978636#178>
> 
> No reason provided either. This stinks. I’m v̲e̲r̲y̲ disappointed.
> Debian is becoming untenable. Years ago, I had hoped it won’t.
> 
> bye,
> //mirabilos

Hi Thorsten,

Sent privately, I hope you don't mind.

I very much like you, and appreciate the work you're doing in Debian.
However, I would not like at all if this is the start of yet-another
drama in Debian. We had enough of this.

Instead of complaining about change, it'd be nice if instead, you were
embracing it, and tried to contribute fixes for the parts that you're
maintaining in Debian. I'm not asking you to be enthusiastic about
changes you don't like, but maybe you could at least tried to understand
others are trying to improve things, rather than destroying your work.

Merging binaries in /usr and getting rid of /bin and /sbin, at the end,
WILL be an improvement. Debian cannot be the last distro not doing the
move, I hope you understand that.

Also, I'm having a hard time understanding why moving binaries around
should just break any system, especially if we have workarounds, like
symlink and/or bind mounts or the like. If non-systemd setups are having
issues, please just fix them... The end result *will* be a better Debian.

Last thing, the discussion happened a long time ago, you had plenty of
time to react, especially before the TC voted. Reacting so late, with
such emotion is really uncalled for.

Cheers,

Thomas Goirand (zigo)

Re: merged /usr considered harmful

[Thomas Goirand]

On 7/15/21 5:08 AM, Thorsten Glaser wrote:
> Guillem Jover dixit:
> 
>> I've been meaning to send a note about this for some time now, but
>> as I feel it keeps getting ignored, it always seems a bit pointless.
> 
> Yeah, I saw this popping up multiple times in that bugreport ☹
> 
>> But in any case, given that merged-usr-via-aliased-dirs is not really
>> supported by dpkg anyway, it is broken by design [B], I have no
> 
> Time for another GR?

Please don't! This isn't funny...

Thomas

Re: merged /usr considered harmful

[Marc Haber]

On Fri, 16 Jul 2021 01:44:54 + (UTC), Thorsten Glaser
 wrote:
>Marc Haber dixit:
>>think we can afford an additional time sink at the moment. Please, get
>
>While that’s true…

You conveniently snipped the "I don't" which turns your quote into the
opposite that I wanted to say.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: merged /usr considered harmful

[Thorsten Glaser]

Marc Haber dixit:

>think we can afford an additional time sink at the moment. Please, get

While that’s true…

>Can we please delay this discussion until after the release? I don't

… we can’t afford to: the TC discussion becomes valid as soon as
bullseye is released, which is in two weeks, and the people who
want to make Debian into a Fedora/RedHat/systemd-OS derivative
are going to rely on it and make our lives harder immediately.
They have proven time and time again, cf. #921012, #964139, that
they’re interested in actively breaking nōn-systemd users’ cases,
even despite policy to the contrary (basically ignoring the latter
until they managed to change policy to their likes).

>bullseye out of the door first, then decide how many existing users
>we're going to drive away from Debian in the next round.

*sigh* and isn’t that true…

I *really* don’t get why…

ⓐ these things aren’t done in a derivative that’s *really* close
  to Debian proper but can do all the funky new stuff, preserving
  support for the old stuff in Debian itself, and…

ⓑ usrmerge is “needed” anyway; we were working rather well with the
  previous (and rather-recently-introduced) model of “either /usr
  must be on the same filesystem as / or you must use an initrd to
  mount it”.

Frankly, usrmerge is WORSE then what we had before, in all possible
ways. People are going to write unportable scripts and programs, for
example. Symlink farming and moving is also not going to cut it (also,
rules like “if ed(1) is installed, /bin/ed must be able to call it”
is where other distros failed during moving stuff to /usr).

Why is there such heavy incentive to break things that work, for any
price?

Disappointed, and having spent a day crossgrading and moving from
sid to bullseye,
//mirabilos
PS: Please keep me in Cc, I’m not subscribed here, too high-volume
PPS: This is really draining energy. I just refused adopting a package
 I use and which is rather useful because I just can’t any more.
 And there is flooding and… stuff.
-- 
22:59⎜ glaub ich termkit is kompliziert | glabe nicht das man
damit schneller arbeitet | reizüberflutung │ wie windows │ alles evil
zuviel bilder │ wie ein spiel | 23:00⎜ die meisten raffen auch
nicht mehr von windows | 23:01⎜ bilderbücher sind ja auch nich
wirklich verbreitet als erwachsenen literatur   ‣ who needs GUIs thus?

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Sean Whitton]

Hello,

On Thu 15 Jul 2021 at 09:56AM +02, Jonathan Carter wrote:

> Hi Sean
>
> On 2021/07/15 09:04, Sean Whitton wrote:
>> Just to confirm, when you say "merged-usr-via-aliased-dirs", you mean
>> what I would get if I typed 'debootstrap bullseye /foo', right?
>>
>> I would like to note that the TC decision did not specify any particular
>> implementation of merged-/usr.  It was just about whether to continue to
>> try to support both.
>
> I think a more detailed explanation/expansion/clarification on what
> exactly this means (and ideally also the rationale behind) that in the
> bug report would be appreciated.

You're right, it would have been good if our Bits mail had linked to
some other messages in that thread rather than just the statement of the
result of the vote.  I'm sorry we didn't spot that before sending it.

Additionally, as someone else was kind enough to point out to me
off-list, my statement that "the TC decision did not specify any
particular implementation of merged-/usr" was rather misleading.  What I
should have written was that we did not specify any particular
implementation of the *migration* to merged-/usr for existing systems.

ISTM that "merged-usr-via-aliased-dirs" could refer to the migration
path implemented by the usrmerge package, and/or simply the replacement
of the directories /lib, /bin etc. with symlinks.  To the extent that it
refers to the latter, the TC decision does indeed specify that we will
implement merged-/usr using merged-usr-via-aliased-dirs.

Here are some useful messages we should have linked to:
<https://bugs.debian.org/978636#128>
<https://bugs.debian.org/978636#143>
<https://bugs.debian.org/978636#153>

and of course
<https://lists.debian.org/debian-devel-announce/2019/03/msg1.html>

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Jonathan Carter]

On 2021/07/15 10:47, Marc Haber wrote:
> Can we please delay this discussion until after the release?

To be clear, I was requesting further details from the TC, not a
re-evaluation or further discussion.

-Jonathan

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Luca Boccassi]

On Wed, 2021-07-14 at 23:40 +0200, Guillem Jover wrote:
> On Wed, 2021-07-14 at 19:54:56 +, Thorsten Glaser wrote:
> > Sean Whitton dixit:
> > > * #978636 move to merged-usr-only?
> > > 
> > >  We were asked to decide whether or not Debian 'bookworm' should
> > >  continue to support systems which are not using the merged-usr
> > >  filesystem layout.  We decided that support should not continue beyond
> > >  Debian 'bullseye'.
> > 
> > What? WHAT? ＷＨＡＴ？
> > 
> > >  The decision is captured here:
> > >  <https://bugs.debian.org/978636#178>
> > 
> > No reason provided either. This stinks. I’m v̲e̲r̲y̲ disappointed.
> > Debian is becoming untenable. Years ago, I had hoped it won’t.
> 
> I've been meaning to send a note about this for some time now, but
> as I feel it keeps getting ignored, it always seems a bit pointless.
> 
> But in any case, given that merged-usr-via-aliased-dirs is not really
> supported by dpkg anyway, it is broken by design [B], I have no
> intention whatsoever to break any of my systems with such layout going
> forward, I'm thus planning to spend any necessary volunteer time
> implementing any fix, workaround or solution required to avoid having
> to use it, in detriment of other Debian volunteer time. I already
> started some time ago with dpkg-fsys-usrunmess(8), present already in
> the upcoming bullseye release.
> 
> [B] 
> <https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Does_dpkg_support_merged-.2Fusr-via-aliased-dirs.3F>
> 
> Thanks,
> Guillem

Hi,

As it has been said and written many times already, in reality this is
not broken by design at all and in fact it is the only successful
strategy that has been deployed by other distros - it's what is being
called merged-usr-via-moves-and-symlink-farms that is broken. We can
say this with certainty because both approaches have been tried, so
there's actual real-world data to look at. Just go look at the absolute
mess that Suse got themselves into by following that solution - a 10-
years-long massive half-done-never-finished headache that took an
inordinate amount of work to back out of, and move to the actual
working solution that everybody else are using - merged-usr-via-
aliased-dirs. On the other hand Fedora/RHEL had a smooth and simple
transition using merged-usr-via-aliased-dirs, and that was the end of
it.

Dpkg has some very minor bugs that rpm/dnf/yum/zypper/whatever do not
suffer from. So what? It is perfectly normal as it's software and all
softwares have bugs. They could be fixed, worked around, or ignored,
like all other bugs.

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Marc Haber]

On Thu, 15 Jul 2021 09:56:18 +0200, Jonathan Carter 
wrote:
>On 2021/07/15 09:04, Sean Whitton wrote:
>> Just to confirm, when you say "merged-usr-via-aliased-dirs", you mean
>> what I would get if I typed 'debootstrap bullseye /foo', right?
>> 
>> I would like to note that the TC decision did not specify any particular
>> implementation of merged-/usr.  It was just about whether to continue to
>> try to support both.
>
>I think a more detailed explanation/expansion/clarification on what
>exactly this means (and ideally also the rationale behind) that in the
>bug report would be appreciated.

Can we please delay this discussion until after the release? I don't
think we can afford an additional time sink at the moment. Please, get
bullseye out of the door first, then decide how many existing users
we're going to drive away from Debian in the next round.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Jonathan Carter]

Hi Sean

On 2021/07/15 09:04, Sean Whitton wrote:
> Just to confirm, when you say "merged-usr-via-aliased-dirs", you mean
> what I would get if I typed 'debootstrap bullseye /foo', right?
> 
> I would like to note that the TC decision did not specify any particular
> implementation of merged-/usr.  It was just about whether to continue to
> try to support both.

I think a more detailed explanation/expansion/clarification on what
exactly this means (and ideally also the rationale behind) that in the
bug report would be appreciated.

thanks,

-Jonathan

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Sean Whitton]

Hello Guillem,

On Wed 14 Jul 2021 at 11:40PM +02, Guillem Jover wrote:

> On Wed, 2021-07-14 at 19:54:56 +, Thorsten Glaser wrote:
>> Sean Whitton dixit:
>> >* #978636 move to merged-usr-only?
>> >
>> >  We were asked to decide whether or not Debian 'bookworm' should
>> >  continue to support systems which are not using the merged-usr
>> >  filesystem layout.  We decided that support should not continue beyond
>> >  Debian 'bullseye'.
>>
>> What? WHAT? ＷＨＡＴ？
>>
>> >  The decision is captured here:
>> >  <https://bugs.debian.org/978636#178>
>>
>> No reason provided either. This stinks. I’m v̲e̲r̲y̲ disappointed.
>> Debian is becoming untenable. Years ago, I had hoped it won’t.
>
> I've been meaning to send a note about this for some time now, but
> as I feel it keeps getting ignored, it always seems a bit pointless.
>
> But in any case, given that merged-usr-via-aliased-dirs is not really
> supported by dpkg anyway, it is broken by design [B], I have no
> intention whatsoever to break any of my systems with such layout going
> forward, I'm thus planning to spend any necessary volunteer time
> implementing any fix, workaround or solution required to avoid having
> to use it, in detriment of other Debian volunteer time. I already
> started some time ago with dpkg-fsys-usrunmess(8), present already in
> the upcoming bullseye release.
>
> [B] 
> <https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Does_dpkg_support_merged-.2Fusr-via-aliased-dirs.3F>

Just to confirm, when you say "merged-usr-via-aliased-dirs", you mean
what I would get if I typed 'debootstrap bullseye /foo', right?

I would like to note that the TC decision did not specify any particular
implementation of merged-/usr.  It was just about whether to continue to
try to support both.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: merged /usr considered harmful

[Thorsten Glaser]

Guillem Jover dixit:

>I've been meaning to send a note about this for some time now, but
>as I feel it keeps getting ignored, it always seems a bit pointless.

Yeah, I saw this popping up multiple times in that bugreport ☹

>But in any case, given that merged-usr-via-aliased-dirs is not really
>supported by dpkg anyway, it is broken by design [B], I have no

Time for another GR? Leaving Debian behind?

>intention whatsoever to break any of my systems with such layout going

Yeah, this totally caught me by surprise. I guess I’ll have to
figure out how to switch *all* my systems from sid to bullseye
*fast*, now. This also effectively ends debian-ports work for me…

Not amused,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Guillem Jover]

On Wed, 2021-07-14 at 19:54:56 +, Thorsten Glaser wrote:
> Sean Whitton dixit:
> >* #978636 move to merged-usr-only?
> >
> >  We were asked to decide whether or not Debian 'bookworm' should
> >  continue to support systems which are not using the merged-usr
> >  filesystem layout.  We decided that support should not continue beyond
> >  Debian 'bullseye'.
> 
> What? WHAT? ＷＨＡＴ？
> 
> >  The decision is captured here:
> >  <https://bugs.debian.org/978636#178>
> 
> No reason provided either. This stinks. I’m v̲e̲r̲y̲ disappointed.
> Debian is becoming untenable. Years ago, I had hoped it won’t.

I've been meaning to send a note about this for some time now, but
as I feel it keeps getting ignored, it always seems a bit pointless.

But in any case, given that merged-usr-via-aliased-dirs is not really
supported by dpkg anyway, it is broken by design [B], I have no
intention whatsoever to break any of my systems with such layout going
forward, I'm thus planning to spend any necessary volunteer time
implementing any fix, workaround or solution required to avoid having
to use it, in detriment of other Debian volunteer time. I already
started some time ago with dpkg-fsys-usrunmess(8), present already in
the upcoming bullseye release.

[B] 
<https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Does_dpkg_support_merged-.2Fusr-via-aliased-dirs.3F>

Thanks,
Guillem

merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Thorsten Glaser]

Sean Whitton dixit:

>* #978636 move to merged-usr-only?
>
>  We were asked to decide whether or not Debian 'bookworm' should
>  continue to support systems which are not using the merged-usr
>  filesystem layout.  We decided that support should not continue beyond
>  Debian 'bullseye'.

What? WHAT? ＷＨＡＴ？

>  The decision is captured here:
>  <https://bugs.debian.org/978636#178>

No reason provided either. This stinks. I’m v̲e̲r̲y̲ disappointed.
Debian is becoming untenable. Years ago, I had hoped it won’t.

bye,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general

Re: move to merged-usr-only?

[Simon McVittie]

On Thu, 21 Jan 2021 at 06:03:52 +0100, Guillem Jover wrote:
> I mentioned this before, this does not look specific to whatever
> method to do merged-/usr, instead this seems like a general dpkg
> problem related to missing fsync() on the directories during unpacks

It's great news that someone has a theory on this. I opened
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949395> for this
a while ago, but since I have no idea how to reproduce it, I wasn't able
to get anywhere.

> I don't see why this could not affect also merged-/usr-via-aliased-dirs
> systems when moving other pathnames around.

I expect it could affect any move between directories, but it's usually
only going to have a serious impact when: a file was previously in
a higher-precedence member of a search path, it is being moved to a
lower-precedence member of the same search path, and the higher-precedence
member of the search path is still searched by the loader, causing the
old file to be loaded. In other situations, the old file wastes some disk
space but usually won't be actively harmful.

Moving shared libraries from /lib/MULTIARCH to /usr/lib/MULTIARCH happens
to be a relatively frequently-done move that fits that description.
Most of our other search paths either have length 1 (so the more serious
impact won't occur because no move can take place), or add new entries
with higher precedence than old entries, for example when GTK started to
load /usr/lib/x86_64-linux-gnu/gtk-*/modules at a higher precedence than
/usr/lib/gtk-*/modules (so the more serious impact won't occur because
there is no reason why we would want to move modules from the multiarch
location to the pre-multiarch location).

I think the semantics of ldconfig make this worse for shared libraries
specifically, because even if dpkg correctly removes the SONAME
symlink in /lib for a library that has moved into /usr/lib, ldconfig
will helpfully re-create it as long as the real file exists.
(For example in the GLib case, as long as /lib/MA/libglib-2.0.so.0.4200.0
continues to exist, ldconfig will re-create /lib/MA/libglib-2.0.so.0,
with the unwanted effect of shadowing /usr/lib/MA/libglib-2.0.so.0.)

Moving executables between directories in PATH could maybe run into a
similar problem, part of which would be avoided by merged /usr (because
moving between /bin and /usr/bin, or /sbin and /usr/sbin, becomes a no-op)
but part of which is not (moving between [/usr]/bin and [/usr]/sbin could
still trigger something similar, which merged /usr would not address).

smcv

Re: move to merged-usr-only?

[Guillem Jover]

*Sigh*, replying only now because I find this topic exhausting, draining,
tiresome and I'd rather be doing productive stuff instead of rehashing
stuff for the nth time. :( Even though I've also tried to document and
summarize this in the dpkg FAQ and the dpkg MergedUsr wiki page, but I
assume I'm not explaining myself clearly because this is not getting
through… :(

On Fri, 2020-11-20 at 19:35:07 +, Simon McVittie wrote:
> On Fri, 20 Nov 2020 at 11:12:20 +0100, Ansgar wrote:
> > On Fri, 2020-11-20 at 10:19 +0100, Adam Borowski wrote:
> > > On Fri, Nov 20, 2020 at 09:35:42AM +0100, Ansgar wrote:
> > > > As far as I know nothing broke catastrophically over the last releases
> > > > with merged-/usr.
> > > 
> > > Unless you look at dpkg or attempts at speeding up bootstrap.
> > > 
> > > See 
> > > https://salsa.debian.org/glibc-team/glibc/-/commit/49d137c4392cb1144f2313f78f31466aaa169b75
> > > for an example.
> 
> Trying to transition from /lib to /usr/lib in the way that is advocated
> by some people who don't like usrmerge (one package at a time, without
> using usrmerge or something equivalent) can unfortunately *also* cause
> transitional brokenness: see
> <https://salsa.debian.org/gnome-team/glib/-/commit/1f9c505abe2639296615d13c048227a3df378576>.

I mentioned this before, this does not look specific to whatever
method to do merged-/usr, instead this seems like a general dpkg
problem related to missing fsync() on the directories during unpacks:

  <https://lists.debian.org/debian-devel/2020/02/msg00477.html>

I don't see why this could not affect also merged-/usr-via-aliased-dirs
systems when moving other pathnames around.

I still need to sit down and fix it, I guess during 1.21.x…

> > The good news here is that shipping bash as /usr/bin/bash (instead of
> > /bin/bash) solves that problems as dpkg will just install it under
> > /usr/bin/bash.  No aliasing over symlinks involved.

Err, no, it does definitely not solve any such problem, the aliasing
via directories is still going to be there (the problem will just show
up instead in the other direction). This would just imply trying to
force onto everyone getting a broken system.

> So we need a way to get there from here. The only possibilities I can
> see for that within the framework of a dpkg-based OS are:
> 
> * Aliasing via symlinks:
>   Something magics /bin -> usr/bin, etc., symlinks into existence,
>   and dpkg continues to tolerate unpacking over them, providing
>   a per-installation flag day to move to merged /usr. usrmerge is
>   an implementation of this approach, debootstrap --merged-usr is
>   another. Individual systems can do this transition at any time (many
>   have already done so), and they will get the benefit of merged /usr
>   (in particular, a class of avoidable bugs can no longer affect them)
>   after they have passed the flag day.

Fortunately the breakage stemming from this approach can now be fixed
starting with dpkg 1.20.6, which contains the new dpkg-fsys-usrunmess
tool.

> * Package-by-package migration:
>   For every package that ships a file in /bin, /sbin, /lib* whose path
>   might have been hard-coded elsewhere, the maintainer of that package
>   takes action to move the file into /usr. If the file's full path might
>   have been hard-coded elsewhere (/bin/bash, etc.), the maintainer
>   scripts must additionally create an unmanaged symlink
>   /bin/bash -> /usr/bin/bash, etc. - similar to what was done to move
>   /usr/bin/chacl in src:acl to /bin, but in reverse. And then, to get the
>   benefits of merged /usr, we have to wait for *every* package to stop
>   shipping anything in /bin, /sbin, /lib*, and *then* have a usrmerge-like
>   per-installation flag day at which the collection of symlinks /bin/bash
>   -> /usr/bin/bash, etc. are replaced by a single symlink /bin -> usr/bin.

We only need the unmanaged symlinks generated by maintscripts due to
the merged-/usr-via-aliased-dirs hack. :( A transition could have been
done automatically instead, as I've mentioned in the past. See below.

But if the intention is to end up with a merged-/usr-via-aliased-dirs
then this approach seems rather pointless TBH.


Instead what I've mentioned multiple times in the past is that this
could have been done (and could still be done), by say a new debhelper
compat level that automatically moves all the pathnames from «/» to
«/usr», during building, and creates the symlink farms under «/». This
would require reverting the merged-/usr-via-aliased-dirs mess (which is
now possible) and banning that method completely, so that we can avoid
the mess with the required maintainer scripts. Which would imply at
least, that:

  * there are no directory aliasing issu

Re: Bug#978636: move to merged-usr-only?

[Marco d'Itri]

On Jan 02, Matthias Klumpp  wrote:

> You wouldn't have to depend on PackageKit, the offline-upgrades stuff
> can be implemented by other tools that aren't PK as well (you could
> pretty much use the same mechanism, with some safeguards to not
> interfere with PK/GNOME). However, ensuring that no service with
> ProtectSystem starts may be a problem, as that feature is used quite
> extensively by services that are part of the systemd project, and I
> don't know whether it is possible to exclude them all from a potential
> usrmerge target without causing other problems.
I am not even sure that this is still an issue: Michael Biebl and me did 
a few tests (Debian 10, testing and Ubuntu 20.04) and convert-usrmerge 
never failed.

Is anybody actually able to reproduce that on a Debian >= 10 system?
Again, nothing bad will happen if you try and trigger that code path: 
just follow the instructions that will tell you to reboot the system and 
then run convert-usrmerge again.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Bug#978636: move to merged-usr-only?

[Matthias Klumpp]

Am Di., 29. Dez. 2020 um 23:13 Uhr schrieb Marco d'Itri :
>
> On Dec 29, Matthias Klumpp  wrote:
>
> > For package upgrades, we can already perform so-called "offline
> > upgrades", where the system reboots into a smaller systemd target,
> > applies all updates and then reboots again into the updated system.
> > This is implemented in PackageKit as an option and used by GNOME.
> > Fwupd uses similar concepts for certain firmware updates as well.
> > Maybe hooking into these facilities is also an option for the usrmerge
> > upgrade? (unless of course systemd is still interfering even in a
> > minimal target, that would be a dealbreaker).
> It depends on which units are started (this trouble is caused by the
> ProtectSystem directive and maybe others like it): having usrmerge
> stop and then restart the daemons involved would work as well, but I am
> not sure of how many corner cases (gdm...) we would find before just
> rebooting would become simpler again.
> I think that depending on PackageKit would be more complex than an
> initramfs-tools hook, since just about everybody is supposed to have
> that around.

You wouldn't have to depend on PackageKit, the offline-upgrades stuff
can be implemented by other tools that aren't PK as well (you could
pretty much use the same mechanism, with some safeguards to not
interfere with PK/GNOME). However, ensuring that no service with
ProtectSystem starts may be a problem, as that feature is used quite
extensively by services that are part of the systemd project, and I
don't know whether it is possible to exclude them all from a potential
usrmerge target without causing other problems.

Also, of course this would only work on systemd systems, in the same
way that the initramfs-tools solution won't work for Dracut users.
Looks like quite a tricky problem, but one that could definitely be
addressed by the project.

Cheers,
Matthias



-- 
I welcome VSRE emails. See http://vsre.info/

Re: Bug#978636: move to merged-usr-only?

[Ben Hutchings]

On Tue, 2020-12-29 at 23:12 +0100, Marco d'Itri wrote:
[...]
> I think that depending on PackageKit would be more complex than an 
> initramfs-tools hook, since just about everybody is supposed to have 
> that around.

I'm afraid not - dracut, tiny-initramfs, and custom kernels that don't
need an initramfs are also supported options.

Ben.

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment destroyed
- Carolyn Scheppner


signature.asc
Description: This is a digitally signed message part

Re: Bug#978636: move to merged-usr-only?

[Marco d'Itri]

On Dec 29, Matthias Klumpp  wrote:

> For package upgrades, we can already perform so-called "offline
> upgrades", where the system reboots into a smaller systemd target,
> applies all updates and then reboots again into the updated system.
> This is implemented in PackageKit as an option and used by GNOME.
> Fwupd uses similar concepts for certain firmware updates as well.
> Maybe hooking into these facilities is also an option for the usrmerge
> upgrade? (unless of course systemd is still interfering even in a
> minimal target, that would be a dealbreaker).
It depends on which units are started (this trouble is caused by the
ProtectSystem directive and maybe others like it): having usrmerge 
stop and then restart the daemons involved would work as well, but I am 
not sure of how many corner cases (gdm...) we would find before just 
rebooting would become simpler again.
I think that depending on PackageKit would be more complex than an 
initramfs-tools hook, since just about everybody is supposed to have 
that around.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Bug#978636: move to merged-usr-only?

[Matthias Klumpp]

Am Di., 29. Dez. 2020 um 17:39 Uhr schrieb Marco d'Itri :
>
> On Dec 29, Ansgar  wrote:
>
> > as suggested in [1], I would like to see Debian to move to support
> > only the merged-usr filesystem layout.  This would simplfy things for
> > the future and also address the problem with installing files under
> > aliased trees that dpkg has to do for both variants to be supported.
> As the architect of the Debian merged-usr transition, I agree: removing
> support for unmerged systems would simplify many things.
> Thank you Ansgar for bringing this to the CTTE.

Indeed!

> > I'm not asking the committee to decide on a concrete technical
> > implementation for this.  Obviously we would need to also implement a
> > migration path for legacy installations for a move to merged-usr-only
> > to be implemented.  This also isn't relevant for Debian 11 (bullseye),
> > but I would like to have enough time in the Debian 12 (bookworm)
> > cycle.
> Agreed.
> FWIW: we have had for a long time a reliable migration method, the
> usrmerge package.
> Except that on a live system it requires a reboot mid-conversion (due to
> bind mounts created by systemd): since this is inconvenient and mildly
> scary I did not propose wider adoption for buster.
> The best workaround would probably be to run it from the initramfs, but
> I have not been able to actually make this[1] work: I expect that
> somebody who knows initramfs-tools better than I do can fix it quickly.

For package upgrades, we can already perform so-called "offline
upgrades", where the system reboots into a smaller systemd target,
applies all updates and then reboots again into the updated system.
This is implemented in PackageKit as an option and used by GNOME.
Fwupd uses similar concepts for certain firmware updates as well.
Maybe hooking into these facilities is also an option for the usrmerge
upgrade? (unless of course systemd is still interfering even in a
minimal target, that would be a dealbreaker).
More info about offline-upgrades can be found at [1], could be
interesting to look into.

This discussion is probably OT through for the issue at hand (*if* we
make that switch, not the *how* we make it in particular).

Cheers,
Matthias

[1]: 
https://www.freedesktop.org/software/systemd/man/systemd.offline-updates.html

-- 
I welcome VSRE emails. See http://vsre.info/

Re: Bug#978636: move to merged-usr-only?

[Marco d'Itri]

On Dec 29, Ansgar  wrote:

> as suggested in [1], I would like to see Debian to move to support
> only the merged-usr filesystem layout.  This would simplfy things for
> the future and also address the problem with installing files under
> aliased trees that dpkg has to do for both variants to be supported.
As the architect of the Debian merged-usr transition, I agree: removing 
support for unmerged systems would simplify many things.
Thank you Ansgar for bringing this to the CTTE.

> I'm not asking the committee to decide on a concrete technical
> implementation for this.  Obviously we would need to also implement a
> migration path for legacy installations for a move to merged-usr-only
> to be implemented.  This also isn't relevant for Debian 11 (bullseye),
> but I would like to have enough time in the Debian 12 (bookworm)
> cycle.
Agreed.
FWIW: we have had for a long time a reliable migration method, the
usrmerge package.
Except that on a live system it requires a reboot mid-conversion (due to
bind mounts created by systemd): since this is inconvenient and mildly
scary I did not propose wider adoption for buster.
The best workaround would probably be to run it from the initramfs, but
I have not been able to actually make this[1] work: I expect that 
somebody who knows initramfs-tools better than I do can fix it quickly.

[1] https://salsa.debian.org/md/usrmerge/-/tree/initramfs

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#978636: move to merged-usr-only?

[Ansgar]

Package: tech-ctte
X-Debbugs-Cc: debian-devel@lists.debian.org

Hi,

as suggested in [1], I would like to see Debian to move to support
only the merged-usr filesystem layout.  This would simplfy things for
the future and also address the problem with installing files under
aliased trees that dpkg has to do for both variants to be supported.

merged-usr has been the default for new installations since the last
release and (as far as I am aware) no world-breaking bugs have
happened since; some environments such as buildd chroots still do not
use merged-usr.

I would like to ask the technical committee to decide whether we want
to move to merged-usr-only.  It seems to be a case of overlapping
jurisdiction (6.1.2 in the constitution).

I'm not asking the committee to decide on a concrete technical
implementation for this.  Obviously we would need to also implement a
migration path for legacy installations for a move to merged-usr-only
to be implemented.  This also isn't relevant for Debian 11 (bullseye),
but I would like to have enough time in the Debian 12 (bookworm)
cycle.

Ansgar

[1]: https://lists.debian.org/debian-devel/2020/11/#00232
 continued in December: https://lists.debian.org/debian-devel/2020/12/#00386

Re: move to merged-usr-only?

[Christoph Biedl]

Andreas Metzler wrote...

> I am all for declaring a cutoff date (and release) which makes usrmerge
> mandatory and the only supported setup. (Or alternatively make usrmerge
> an unsupported setup.) The current state where we are trying to support
> both and end up dealing with fallout and cannot make real progress to
> the clean state (bash being shipped as /usr/bin/bash and therefore dpkg
> knowing about it) is a waste of developer time.

Indeed. I just lost two hours to realize the build failures of one of my
packages resulted from upstream being post-usrmerge in mind while the
buildds are appearently pre-, and with my local build chroots already
migrated I hadn't noticed beforehand. And now I can only hope the
resulting binaries will run everywhere. The sooner we get out of this
mess the better.

Christoph


signature.asc
Description: PGP signature

Re: move to merged-usr-only?

[Andreas Metzler]

On 2020-11-20 Ansgar  wrote:
> I would like to propose to plan to move to support merged-usr-only over
> the following releases.  The motivation is bugs like [1] where upstream
> developers just use `/usr/bin/rm` (or other binaries, or user scripts
> using /usr/bin/bash, or ...) unconditionally; this was already a
> motivation to adopt merged-/usr as a default for me.

> As far as I know nothing broke catastrophically over the last releases
> with merged-/usr.

> Alternatively, a team could form that preemptively looks at such issues
> and fixes them, ideally upstream.

> So a possible idea would be to:

>  - For Debian 12 (bookworm): make it mandatory to migrate old systems to
>merged-/usr on upgrade. Possibly by allowing the existing usrmerge
>program to run from the initramfs.

>  - For Debian 13 (trixie): packages should no longer install to /bin,
>/sbin, /lib, but to the respective locations under /usr.

Hello Ansgar,

I am all for declaring a cutoff date (and release) which makes usrmerge
mandatory and the only supported setup. (Or alternatively make usrmerge
an unsupported setup.) The current state where we are trying to support
both and end up dealing with fallout and cannot make real progress to
the clean state (bash being shipped as /usr/bin/bash and therefore dpkg
knowing about it) is a waste of developer time.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: move to merged-usr-only?

[Ansgar]

On Sat, 2020-11-21 at 11:07 +, Paul Wise wrote:
> On Sat, Nov 21, 2020 at 10:33 AM Ansgar wrote:
> 
> > The goal is to have /bin and /usr/bin to have identical contents.
> > So one would need a new /bin/python3 -> /usr/bin/python3 symlinks
> 
> Those seem unnecessary to me, since we have $PATH and nothing should
> be using /bin/python3 at this stage.

We have $PATH, yet there are bugs that come from using `/usr/bin/rm` as
mentioned in my inital mail.  There is no reason to assume that the
same doesn't happen in the other direction.

I've already seen people using `#!/bin/python` as interpreter a long
time ago (before Debian had merged-/usr by default).  One can try to
educate people that this is wrong because some binaries were
historically only available in /usr (due to too small root disk, but a
larger disk for /home), but why bother when we can just get rid of the
problem and even already have done so partly?

Or you can say we ignore that error class for a few more years and only
address half of it and then the other half in X years.

Ansgar

Re: move to merged-usr-only?

[Paul Wise]

On Sat, Nov 21, 2020 at 10:33 AM Ansgar wrote:

> The goal is to have /bin and /usr/bin to have identical contents.
> So one would need a new /bin/python3 -> /usr/bin/python3 symlinks

Those seem unnecessary to me, since we have $PATH and nothing should
be using /bin/python3 at this stage.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: move to merged-usr-only?

[Ansgar]

On Sat, 2020-11-21 at 02:01 +, Paul Wise wrote:
> On Fri, Nov 20, 2020 at 7:35 PM Simon McVittie wrote:
> 
> > Package-by-package migration touches a large number of packages
> 
> By my count there are 1712 binary packages from X source packages
> installing things outside /etc /usr /var

The goal is to have /bin and /usr/bin to have identical contents.  If
one wishes to achieve that via symlinks for every single binaries, you
not only need symlinks in /bin for binaries previously there, but moved
to /usr/bin, but also for binaries that already are in /usr/bin.

So one would need a new /bin/python3 -> /usr/bin/python3 symlinks in
addition to the /bin/bash -> /usr/bin/bash symlink discussed here. This
affects many more packages.

Starting a 10-year[1] migration for the small part (move bash to
/usr/bin, add /bin/bash -> /usr/bin/bash) symlink, then maybe[2] start
*another* *multi-year) migration after that, and then getting there
isn't a great outlook for me.  (At that time migration to merged-/usr
for the remaining systems would no longer be a worry either way as
presumably only very few installations without merged-/usr would exist
anyway and no migration would be needed, i.e., like the i386 -> amd64
cross-upgrade nobody really worries about any more.)

Ansgar

  [1]: https://lists.debian.org/debian-devel/2018/11/msg00354.html
  [2]: cf. OpenSuSE or suggestions to never do that and instead wait 
   until nobody uses /bin/sh any longer.  If you suggest to do 
   package-by-package migrations, please at least argue why Debian
   wouldn't end in the same in-between state as SuSE.

Re: move to merged-usr-only?

[Paul Wise]

On Fri, Nov 20, 2020 at 7:35 PM Simon McVittie wrote:

> Package-by-package migration touches a large number of packages

By my count there are 1712 binary packages from X source packages
installing things outside /etc /usr /var

$ apt-file search --regexp '^/[^euv]' | sed 's/: .*//' | sort -u | wc -l
1712

Many of those are systemd unit files and updating systemd and
debhelper and then rebuilding all of the packages containing systemd
unit files will presumably solve a fair amount of packages.

$ apt-file search --regexp '^/[^euv]' | grep /lib/systemd | sed 's/:
.*//' | sort -u | wc -l
1121

After eliminating systemd unit files, the problem looks less imposing:

$ apt-file search --regexp '^/[^euv]' | grep -v /lib/systemd | sed
's/: .*//' | sort -u | wc -l
733

--
bye,
pabs

https://wiki.debian.org/PaulWise

Re: move to merged-usr-only?

[Simon McVittie]

On Fri, 20 Nov 2020 at 11:12:20 +0100, Ansgar wrote:
> On Fri, 2020-11-20 at 10:19 +0100, Adam Borowski wrote:
> > On Fri, Nov 20, 2020 at 09:35:42AM +0100, Ansgar wrote:
> > > As far as I know nothing broke catastrophically over the last releases
> > > with merged-/usr.
> > 
> > Unless you look at dpkg or attempts at speeding up bootstrap.
> > 
> > See 
> > https://salsa.debian.org/glibc-team/glibc/-/commit/49d137c4392cb1144f2313f78f31466aaa169b75
> > for an example.

Trying to transition from /lib to /usr/lib in the way that is advocated
by some people who don't like usrmerge (one package at a time, without
using usrmerge or something equivalent) can unfortunately *also* cause
transitional brokenness: see
<https://salsa.debian.org/gnome-team/glib/-/commit/1f9c505abe2639296615d13c048227a3df378576>.

(I would appreciate wider testing of the glib2.0 versions in experimental
that attempt to resolve this, particularly by people whose systems are
*not* merged-/usr. Merge requests against the debian/experimental branch
are also welcome.)

> The good news here is that shipping bash as /usr/bin/bash (instead of
> /bin/bash) solves that problems as dpkg will just install it under
> /usr/bin/bash.  No aliasing over symlinks involved.

I do agree with Ansgar that it seems good to have a timeline for making
merged /usr the only supported layout. I don't agree with the implication
that it's trivial to get there. There will probably be regressions -
but we have a lot of clever people in this project, and if we pull the
lever soon after bullseye is released, we have an entire release cycle to
sort out regressions and still be on time for Ansgar's proposed timeline.

(In an attempt to forestall people disputing that merged /usr has benefits:
please see my responses to previous threads on this topic, in particular
<https://lwn.net/ml/debian-devel/20181121140542.ga31...@espresso.pseudorandom.co.uk/>
almost exactly 2 years ago, for quite a lot of words about that which
I will not repeat here.)

I agree that if we were designing a new dpkg-based OS that did not have
legacy/upgrade-path constraints, we should put all the OS files in /usr
in the .deb, and do something centralized to provide symlinks
bin -> usr/bin and so on (either ship them in base-files, or use something
resembling systemd-tmpfiles to make them exist declaratively, or just
create them once during installation).

However, we *do* have legacy/upgrade-path constraints:

* Existing packages have paths like bin/bash in the .deb.

* Existing installed systems have files on disk at paths like /bin/bash.

* We cannot avoid the need for the path /bin/bash to exist (whether
  it's a regular file or involves a symlink /bin -> usr/bin or
  /bin/bash -> /usr/bin/bash), because existing scripts start with
  #!/bin/bash (and similarly /lib/ld-linux.so.2,
  /lib64/ld-linux-x86-64.so.2 etc. must continue to exist at those paths,
  with or without the help of symlinks, otherwise no binaries will run).

So we need a way to get there from here. The only possibilities I can
see for that within the framework of a dpkg-based OS are:

* Aliasing via symlinks:
  Something magics /bin -> usr/bin, etc., symlinks into existence,
  and dpkg continues to tolerate unpacking over them, providing
  a per-installation flag day to move to merged /usr. usrmerge is
  an implementation of this approach, debootstrap --merged-usr is
  another. Individual systems can do this transition at any time (many
  have already done so), and they will get the benefit of merged /usr
  (in particular, a class of avoidable bugs can no longer affect them)
  after they have passed the flag day.

* Package-by-package migration:
  For every package that ships a file in /bin, /sbin, /lib* whose path
  might have been hard-coded elsewhere, the maintainer of that package
  takes action to move the file into /usr. If the file's full path might
  have been hard-coded elsewhere (/bin/bash, etc.), the maintainer
  scripts must additionally create an unmanaged symlink
  /bin/bash -> /usr/bin/bash, etc. - similar to what was done to move
  /usr/bin/chacl in src:acl to /bin, but in reverse. And then, to get the
  benefits of merged /usr, we have to wait for *every* package to stop
  shipping anything in /bin, /sbin, /lib*, and *then* have a usrmerge-like
  per-installation flag day at which the collection of symlinks /bin/bash
  -> /usr/bin/bash, etc. are replaced by a single symlink /bin -> usr/bin.

* Combine those two strategies, while arguing about which one is better,
  and hopefully minimizing the extent to which proponents of one approach
  prevent the other approach from proceeding. (In the absence of consensus,
  this is what is happening in practice.)

Packages like bash that install files whose traditional paths are on
the root filesystem and are hard-coded into other packages c

Re: move to merged-usr-only?

[Luca Boccassi]

On Fri, 2020-11-20 at 09:35 +0100, Ansgar wrote:
> Hi,
> 
> I would like to propose to plan to move to support merged-usr-only over
> the following releases.  The motivation is bugs like [1] where upstream
> developers just use `/usr/bin/rm` (or other binaries, or user scripts
> using /usr/bin/bash, or ...) unconditionally; this was already a
> motivation to adopt merged-/usr as a default for me.
> 
> As far as I know nothing broke catastrophically over the last releases
> with merged-/usr.
> 
> Alternatively, a team could form that preemptively looks at such issues
> and fixes them, ideally upstream.
> 
> So a possible idea would be to:
> 
>  - For Debian 12 (bookworm): make it mandatory to migrate old systems to
>merged-/usr on upgrade. Possibly by allowing the existing usrmerge
>program to run from the initramfs.
> 
>  - For Debian 13 (trixie): packages should no longer install to /bin,
>/sbin, /lib, but to the respective locations under /usr.
> 
> Ansgar
> 
>   [1]: https://bugs.debian.org/973853

+1

Thanks for pushing forward with this!

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Re: move to merged-usr-only?

[Ansgar]

On Fri, 2020-11-20 at 11:12 +0100, Ansgar wrote:
> On Fri, 2020-11-20 at 10:19 +0100, Adam Borowski wrote:
> > So let's make it so a canonical path to a file never includes a directory
> > symlink; if you insist on /usr/bin/rm then /bin/rm should be
> > /bin/{rm->/usr/bin/rm} not /{bin->usr/bin}/rm
> 
> Why ship /bin/rm at all? Seems too complicated and just ends in the
> half-migrated state that SuSE was in last I checked.

Oh, and I forgot: I don't think adding new /bin/python3 ->
/usr/bin/python3 symlinks (repeat for everything else in
/usr/{bin,sbin} and possibly some parts of lib) to all packages is a
desirable goal.

One point is *not* having / to know about the contents /usr.  That was
discussed many times in the past and I don't think we need to revisit
it.

Ansgar

Re: move to merged-usr-only?

[Ansgar]

On Fri, 2020-11-20 at 10:19 +0100, Adam Borowski wrote:
> On Fri, Nov 20, 2020 at 09:35:42AM +0100, Ansgar wrote:
> > I would like to propose to plan to move to support merged-usr-only over
> > the following releases.  The motivation is bugs like [1] where upstream
> > developers just use `/usr/bin/rm` (or other binaries, or user scripts
> > using /usr/bin/bash, or ...) unconditionally; this was already a
> > motivation to adopt merged-/usr as a default for me.
> > 
> > As far as I know nothing broke catastrophically over the last releases
> > with merged-/usr.
> 
> Unless you look at dpkg or attempts at speeding up bootstrap.
> 
> See 
> https://salsa.debian.org/glibc-team/glibc/-/commit/49d137c4392cb1144f2313f78f31466aaa169b75
> for an example.
> 
> As far as I know, dpkg maintainers consider usrmerge to be unsupported,
> and trying to make my own NIH deb installer I see why.

The good news here is that shipping bash as /usr/bin/bash (instead of
/bin/bash) solves that problems as dpkg will just install it under
/usr/bin/bash.  No aliasing over symlinks involved.

You also don't need any special handling for anything in /bin, /sbin as
nothing would be installed there (all packages ship the files in /usr).

> > So a possible idea would be to:
> > 
> >  - For Debian 12 (bookworm): make it mandatory to migrate old systems to
> >merged-/usr on upgrade. Possibly by allowing the existing usrmerge
> >program to run from the initramfs.
> 
> Counterproposal: replace debootstrap with mmdebstrap, which is many times
> faster -- and doesn't support usrmerge at all, or at least disable usrmerge
> in debootstrap in default.

That is unrelated.  Also you don't need special usrmerge support once
all packages ship files under /usr.

If you care about speed: not calling sync() way too often would
probably make dpkg significantly faster and possibly reduce the total
time the system is in an incinsistent state (of half-updated packages),
reducing the chance of system crashes breaking stuff ;-)

If you see the aliasing problem as a large issue, we could also try to
ship files in /usr already for bookworm.

> >  - For Debian 13 (trixie): packages should no longer install to /bin,
> >/sbin, /lib, but to the respective locations under /usr.
> 
> Moving stuff with no mandated path is a good idea, yes.  Alas, it's been
> massively complicated by usrmerge being a thing, and thus you can't just
> ship the file in a new location as you risk a path conflict.

You can just ship /usr/bin/bash instead of /bin/bash in an updated
package.

> So let's make it so a canonical path to a file never includes a directory
> symlink; if you insist on /usr/bin/rm then /bin/rm should be
> /bin/{rm->/usr/bin/rm} not /{bin->usr/bin}/rm

Why ship /bin/rm at all? Seems too complicated and just ends in the
half-migrated state that SuSE was in last I checked.

> >   [1]: https://bugs.debian.org/973853
> 
> That's a piece of software for which upstream is Red Hat.  The number of
> people developing on RPM distros is rapidly falling, so this is less and
> less of an issue.

Well, other distributions like Debian, Ubuntu, ... also use merged-/usr 
these days.

Ansgar

Re: move to merged-usr-only?

[Adam Borowski]

On Fri, Nov 20, 2020 at 09:35:42AM +0100, Ansgar wrote:
> I would like to propose to plan to move to support merged-usr-only over
> the following releases.  The motivation is bugs like [1] where upstream
> developers just use `/usr/bin/rm` (or other binaries, or user scripts
> using /usr/bin/bash, or ...) unconditionally; this was already a
> motivation to adopt merged-/usr as a default for me.
> 
> As far as I know nothing broke catastrophically over the last releases
> with merged-/usr.

Unless you look at dpkg or attempts at speeding up bootstrap.

See 
https://salsa.debian.org/glibc-team/glibc/-/commit/49d137c4392cb1144f2313f78f31466aaa169b75
for an example.

As far as I know, dpkg maintainers consider usrmerge to be unsupported,
and trying to make my own NIH deb installer I see why.

Some more information:
https://wiki.debian.org/Teams/Dpkg/MergedUsr

A script to recover from usrmerge:
https://www.hadrons.org/~guillem/tmp/unmessusr.pl

> So a possible idea would be to:
> 
>  - For Debian 12 (bookworm): make it mandatory to migrate old systems to
>merged-/usr on upgrade. Possibly by allowing the existing usrmerge
>program to run from the initramfs.

Counterproposal: replace debootstrap with mmdebstrap, which is many times
faster -- and doesn't support usrmerge at all, or at least disable usrmerge
in debootstrap in default.

(My zdebootstrap is mostly vapourware yet, alas.)

>  - For Debian 13 (trixie): packages should no longer install to /bin,
>/sbin, /lib, but to the respective locations under /usr.

Moving stuff with no mandated path is a good idea, yes.  Alas, it's been
massively complicated by usrmerge being a thing, and thus you can't just
ship the file in a new location as you risk a path conflict.

My implementation uses libarchive which flat-out refuses to unpack over a
symlink, for multiple reasons that this conflict is just one of.  [2]

So let's make it so a canonical path to a file never includes a directory
symlink; if you insist on /usr/bin/rm then /bin/rm should be
/bin/{rm->/usr/bin/rm} not /{bin->usr/bin}/rm

>   [1]: https://bugs.debian.org/973853

That's a piece of software for which upstream is Red Hat.  The number of
people developing on RPM distros is rapidly falling, so this is less and
less of an issue.


Meow!

[2]. Some of the issues are mentioned in
https://www.gnu.org/software/tar/manual/html_node/Live-untrusted-data.html
-- generally, until a very recent kernel there's no mechanism to unpack
over a symlink securely even if you try hard, GNU tar and possibly dpkg
don't try at all.
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven giant trumpets are playing in the
⠈⠳⣄ sky.  Your cat demands food.  The priority should be obvious...

move to merged-usr-only?

[Ansgar]

Hi,

I would like to propose to plan to move to support merged-usr-only over
the following releases.  The motivation is bugs like [1] where upstream
developers just use `/usr/bin/rm` (or other binaries, or user scripts
using /usr/bin/bash, or ...) unconditionally; this was already a
motivation to adopt merged-/usr as a default for me.

As far as I know nothing broke catastrophically over the last releases
with merged-/usr.

Alternatively, a team could form that preemptively looks at such issues
and fixes them, ideally upstream.

So a possible idea would be to:

 - For Debian 12 (bookworm): make it mandatory to migrate old systems to
   merged-/usr on upgrade. Possibly by allowing the existing usrmerge
   program to run from the initramfs.

 - For Debian 13 (trixie): packages should no longer install to /bin,
   /sbin, /lib, but to the respective locations under /usr.

Ansgar

  [1]: https://bugs.debian.org/973853

Re: merged-/usr-via-symlinks damage control (was Re: usrmerge -- plan B?)

[Guillem Jover]

On Sun, 2019-02-24 at 03:23:09 +0100, Guillem Jover wrote:
> On Tue, 2019-02-19 at 05:49:24 +0100, Guillem Jover wrote:
[…]
> >   - file a bug on base-installer to request an option to install
> > non-broken systems due to merged-/usr-via-symlinks.
> 
> Done. <https://bugs.debian.org/923091>

This got a patch from Colin Watson (thanks!), but it never got applied
before the release, :( I think the commit description does not fully
reflect the current situation and problems, but I'd take that patch as
is any day.

Doing an installation w/o the broken deployment is not too difficult
though, as long as you know what needs doing:

  - Select expert mode.
  - Do all the steps, until installing the base system.
  - Spawn a shell:
+ Edit /var/lib/dpkg/info/bootstrap-base.posinst,
+ Add --no-merged-usr to the debootstrap call.
  - Proceed with the installation.


In addition this deployment method also breaks:

  - dlocate.
  - apt-file.
  - packages.debian.org's search.
  - find /lib (or any of the other symlinked directories).
  - …

> > And I'm probably going to end up writing a unmerge-usr-via-symlinks
> > script so that people with damaged systems can go back somewhat to a
> > sane state, and to open the possibility for a fully automated migration
> > to a proper and correct merged-/usr w/o all the problems above.
> 
> And I might need to start on this soon enough. :(

I'm not sure I can be bothered TBH.

> In addition, given that most probably Debian buster will end up
> installing broken systems by default. I might end up also looking into
> generating fixed minimal netinst images or mini netboot images with a
> fixed debootstrap, or I guess just cdebootstrap present which has
> sane behavior. But I would definitely not be able host the artifacts
> for those. :/

So this happened in buster, but as per the above, one can "easily" avoid
the breakage, if you know about it. :/

Thanks,
Guillem

Re: merged-/usr-via-symlinks damage control (was Re: usrmerge -- plan B?)

[Russ Allbery]

Julian Andres Klode  writes:

> Having symlinks in /bin and so on would be unclean: We'd have to maintain
> one symlink per binary in /usr. This is a lot of symlinks.

Does the quantity of symlinks matter?

> We also cannot ever get rid of them - it would break the property.

Well, on any given system, once every file in /bin was a symlink to the
same-named file in /usr/bin and we had some guarantee that no new packages
would break this property, we could in theory replace the entire directory
with a symlink.  Doing that feels like it would require new primitives in
the package management software, though, and it might be hard to do
safely.  (It would also create a break point where packages from before
that flag day could no longer be installed on the system.)

> It also fails to handle subdirectories in lib{exec}. We do want
> /usr/lib/systemd and /lib/systemd to be the same.

You can use the same approach recursively and symlink every file.  This is
an old package manager trick that I think Nix is still using to this day,
and which was used to some success by such things as GNU stow (albeit for
different reasons).

-- 
Russ Allbery (r...@debian.org)   

Re: merged-/usr-via-symlinks damage control (was Re: usrmerge -- plan B?)

[Julian Andres Klode]

On Tue, Feb 19, 2019 at 05:49:24AM +0100, Guillem Jover wrote:
> Hi!
> 
> On Tue, 2018-11-20 at 22:16:17 +0100, Adam Borowski wrote:
> > Thus, it seems to me that the plan A for usrmerge has serious downsides for
> > dubious benefits.  What about the plan B I described above?
> 
> So, people still seem to be conflating merged-/usr (the filesystem
> layout) with the different ways to deploy it. Personally I do agree
> that merged-/usr has benefits, and that's why I've f.ex. been switching
> the shared library packages I maintain to do a proper and correct switch
> by installing their files in /usr/lib instead of /lib.
> 
> The underlaying problem with the merged-/usr-via-symlinks is not
> really that it has generated bugs, many transitions we perform incur
> those, for the better. The problem is that it has generated those when
> it was really not necessary in the first place, has made things
> unnecessarily more complicated for everyone, and it's a terrible hack
> trying to reap "quick" benefits at the cost of everyhing else, with
> long lasting consequences even after a full migration to /usr would
> have been finished. And here's why:
> 
> 1) The merged-/usr-via-symlinks deployment method used by both
>debootstrap and usrmerge, means that those systems will get
>permanent filesystem aliasing problems, forever. Even when all
>files might have been moved to their /usr counterparts in the
>packages! This is due to the fact that different pathnames can
>end up pointing (before any canonicalization!) to the same dentry.

This is IMO the most important feature of usrmerge: It does not matter
whether you use /usr/$bar or /$bar, you'll get the same result. Hence
/bin is a symlink to /usr/bin and so on, so you get the same binaries
and libraries in both places.

Having symlinks in /bin and so on would be unclean: We'd have to maintain
one symlink per binary in /usr. This is a lot of symlinks. We also cannot
ever get rid of them - it would break the property.

It also fails to handle subdirectories in lib{exec}. We do want
/usr/lib/systemd and /lib/systemd to be the same.

I don't think there is any other way that sensible handles merging
subdirectories, and therefore, the only reasonable way is to continue
with the current way, and patch up software to normalize /{bin,sbin,lib}
to /usr/bin when they see it on an usrmerged system.

I admit that this is painful, but I think it is worth it.

> 2) It bypasses the packaging system understanding of what is on the
>   filesystem and creates mismatches between what's on binary packages
>   and what's on disk.

I agree that this is a problem. But it seems to me it is a solvable
one.

> 4) Due to having to support the broken merged-/usr-via-symlinks
>deployment, when we want to move the contents of the binary
>packages to the merged-/usr layout, we require now to include tons
>of logic in (probably new) maintainer scripts, when we have been
>trying to remove them altogether. :( With even more files untracked
>by dpkg itself, bypassing the packaging system even more, when the
>compat symlinks could have been shipped in the binary packages.

The solution here seems simple: If you do not want a usrmerged
system, but do want to move binaries to /usr, build a symlink farm
manager into dpkg that automatically creates symlinks in /$foo for
files in /usr/$foo (for some values of $foo), rather than having
packages ship compat themselves.

That would get you support for merged binaries and libraries, but
not for merged lib directories. It's unclear to me how you'd handle
those, hence I mentioned that /lib -> /usr/lib is the only sensible
answer.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Re: merged-/usr-via-symlinks vs a-different-layout

[Sam Hartman]

First, I hear your frustration.
I suspect that our current path is going to lead to a fair bit of pain,
sufficient even that I expect us to make some changes after the release
of buster.  Swallowing that will be hard, but I tend to think we're
being somewhat narrow in which requirements are being considered by the
current plan, and we'll realize that we're not serving the needs of
significant user communities with our current approach.

>>>>> "Guillem" == Guillem Jover  writes:

Guillem> On Sun, 2019-02-24 at 09:23:14 -0500, Sam Hartman wrote:
>> >>>>> "Guillem" == Guillem Jover  writes:
Guillem> On Sun, 2019-02-24 at 08:27:20 +0100, Ansgar wrote:
>> >> Guillem Jover writes: > You are still conflating the concept
>> with >> the deployment. The > underlaying properties of merging
>> /usr is >> that the contents for > directories that are present
>> in both / >> and /usr get merged into > /usr.  >>· >> No, I'm
>> saying that you are proposing yet another different file >>
>> system layout.  Which is quite simple to see: the file system >>
>> would differ.
>> >>
>> >> You just claim it follows similar "ideas" in some way.
>> 
Guillem> Again, no, the important part is that the contents get
Guillem> *moved* properly and *automatically* within the .deb
Guillem> packags,
>> 
>> This is the important part to *you*.

Guillem> This (and the other part you omitted) was an attempt at
Guillem> describing how this alternative deployment method follows
Guillem> the same underlying concept.  And not about how it is
Guillem> important to me.
Guillem> Sure (even though that was unrelated to my point), and I've
Guillem> acknowledged that in previous threads. I do understand some
Guillem> people might value using a deployment method that gives
Guillem> immediate results so they can use the underlying properties
Guillem> of the merged-/usr right away, and providing a readily
Guillem> packaged solution for that seemed acceptable (even though
Guillem> it complicates packaging and alternative deployments). I
Guillem> can also see the apparent appeal of using directory
Guillem> symlinks, as that avoids the forest of compat symlinks.

I don't have a formal definition of deployment vs concept.
However, I think they are similar to concepts of design+requirements vs
implementation.  (Implementation is similar to what you're calling
deployment, design/requirements are I think what you're similar to
calling concept).

That boundary between design and implementation depends on your
requirements.

In your model, both /bin/true and /usr/bin/true might exist and be
different inodes.  One would be a symlink, one would be presumably a
binary.

In the usrmerge model, that situation never exists.  Instead, if on a
non-usrmerge system, /usr/bin/true doesn't exist, but on a usrmerge
system, /bin/true and /usr/bin/true are the same filesystem entity.

What people are telling you is that they consider that a requirement,
not a detail of the implementation--in your words, they consider that
part of the concept.

I do agree that you are repeating yourself.  I might suggest focusing on
asking *why* people feel this is part of the concept rather than an
implementation detail.  I understand if you're too frustrated or
burned-out to do that, but I'd suggest that would be a good next step
for someone holding your position.


For myself, I consider that important because I believe that managing
the dependencies of the sort of transition you talk about would be more
difficult than the pain of the current approach.  Say that the next
version of bash goes and moves bash to /usr/bin/bash with a
compatibility symlink.  We now have a more complex problem with build
systems.  Today, if you build on a usrmerge system, you run into the
possibility that /usr/bin/bash will be discovered by a build system.
You can avoid this class of problems by not building on a usrmerge
system.  In your deployment, once that package enters the archive, I
need to either guarantee that my build system won't choose
/usr/bin/bash, or I need to depend on a new enough version of bash that
I'm guaranteed to get /usr/bin/bash.  Moreover, because the state space
of packages that are converted and not is larger, the reproducible
builds approach of testing to see if a build veries in this condition is
a lot harder to implement.


In addition, I find the eventual /bin -> /usr/bin symlink critical.
Interfaces like #!/bin/sh are long-standing conventions in POSIX.  We
should not deprecate those interfaces.  Maintaining a certain small set
o

Re: merged-/usr-via-symlinks vs a-different-layout

[Guillem Jover]

On Sun, 2019-02-24 at 09:23:14 -0500, Sam Hartman wrote:
> >>>>> "Guillem" == Guillem Jover  writes:
> Guillem> On Sun, 2019-02-24 at 08:27:20 +0100, Ansgar wrote:
> >> Guillem Jover writes: > You are still conflating the concept with
> >> the deployment. The > underlaying properties of merging /usr is
> >> that the contents for > directories that are present in both /
> >> and /usr get merged into > /usr.
> >>·
> >> No, I'm saying that you are proposing yet another different file
> >> system layout.  Which is quite simple to see: the file system
> >> would differ.
> >>
> >> You just claim it follows similar "ideas" in some way.
> 
> Guillem> Again, no, the important part is that the contents get
> Guillem> *moved* properly and *automatically* within the .deb
> Guillem> packags,
> 
> This is the important part to *you*.

This (and the other part you omitted) was an attempt at describing how
this alternative deployment method follows the same underlying concept.
And not about how it is important to me.

> Other things are important to other people.

Sure (even though that was unrelated to my point), and I've acknowledged
that in previous threads. I do understand some people might value using
a deployment method that gives immediate results so they can use the
underlying properties of the merged-/usr right away, and providing a
readily packaged solution for that seemed acceptable (even though it
complicates packaging and alternative deployments). I can also see the
apparent appeal of using directory symlinks, as that avoids the forest
of compat symlinks.

> Instead of working to understand their requirements, you are saying
> things  like "you are still conflating the concept with the deployment."

Well, if we are trying to communicate, and there's a clear distinction
between concepts/ideas/designs and how to implement/deploy them, taking
issue with trying to avoid conflating them, seems to me like a path to
muddling the discussion. :/

> I ask you to please stop and to instead take the time to understand the
> people who disagree with you.

I do think I have this understanding. I've kept finding, though, extremely
frustrating, draining and exhausting to deal and discuss this issue,
because people pushing forward with the merged-usr-via-symlinks deployment
method have been doing that, even though:

  - we've had sustained technical opposition to it, with complete
disregard to it,
  - it's an irreversible process,
  - it's being forced into all new installations by default,

when not forcing it on new installations, still makes it possible for
people that value the properties of the merged-usr-via-symlinks
deployment method to still get it via the usrmerge package! :(


At this point, I feel I'm repeating myself, which also exhausts me, so
I don't think I have the energy right now to keep discussing this. :(

Thanks,
Guillem

Re: merged-/usr-via-symlinks vs a-different-layout

[Sam Hartman]

> "Guillem" == Guillem Jover  writes:

Guillem> On Sun, 2019-02-24 at 08:27:20 +0100, Ansgar wrote:
>> Guillem Jover writes: > You are still conflating the concept with
>> the deployment. The > underlaying properties of merging /usr is
>> that the contents for > directories that are present in both /
>> and /usr get merged into > /usr.
>> 
>> No, I'm saying that you are proposing yet another different file
>> system layout.  Which is quite simple to see: the file system
>> would differ.
>> 
>> You just claim it follows similar "ideas" in some way.

Guillem> Again, no, the important part is that the contents get
Guillem> *moved* properly and *automatically* within the .deb
Guillem> packags,

This is the important part to *you*.

Other things are important to other people.
Instead of working to understand their requirements, you are saying
things  like "you are still conflating the concept with the deployment."

I ask you to please stop and to instead take the time to understand the
people who disagree with you.

I've found it's a valuable exercise to write up the position of those I
disagree with and get to a point where they say that yes, I've
accurately represented their position.
Then I can talk about why I disagree with that approach.
I urge you to do something similar here.

From where I sit, other people in the discussion actually value ending
up with the symlink from /bin to /usr/bin and from /sbin to /usr/sbin.

I can demonstrate that those symlinks have different technical
properties than a system without those symlinks.
Instead of debating those tradeoffs, you're using language like
"botched the final part," which don't actually lead to building
understanding and actually having a technical debate.

I urge you to work to understand those who disagree with you.

Thanks for your consideration,

--Sam


signature.asc
Description: PGP signature

Re: merged-/usr-via-symlinks vs a-different-layout

[Guillem Jover]

On Sun, 2019-02-24 at 08:27:20 +0100, Ansgar wrote:
> Guillem Jover writes:
> > You are still conflating the concept with the deployment. The
> > underlaying properties of merging /usr is that the contents for
> > directories that are present in both / and /usr get merged into
> > /usr.
> 
> No, I'm saying that you are proposing yet another different file system
> layout.  Which is quite simple to see: the file system would differ.
> 
> You just claim it follows similar "ideas" in some way.

Again, no, the important part is that the contents get *moved*
properly and *automatically* within the .deb packags, the only
difference is that for a transition period we'd have most of those
files that currently live in / as symlinks to /usr. Most of those
(not all, obviously) would eventually disappear.

The main difference between the two deployments is how the move is
done, and how and which compat symlinks are setup.

> I can come up with other variations that move files to /usr too: have
> /bin a symlink to /usr/root/bin (some for other directories).  That
> would also be a different file system layout which shouldn't be called
> "merged-/usr" either.

Err, well sure, because that'd not be merged-/usr, obviously. The
contents would not end up being moved/merged into their counterparts
on /usr. This just looks like a straw man…

> (That would have no filesystem aliasing between /bin and /usr/bin;
> policy has special rules to allow replacing top-level directories with
> symlinks; but besides that it is different for no good reason so I don't
> think it would be a good idea.)

The rationale for the policy and dpkg support for moving directories
into other places and then symlinking them, was for space constrained
purposes (say move /lib to /srv/lib, or even /usr to /srv/usr). These
never create filesystem aliasing problems, because no one had before
tried to point those dpkg owned directories contents into another dpkg
owned directory and then symlinking the directories. This should be
obvious from the fact that before the merged-/usr-via-symlinks hack
got forced in, many packages needed to be changed (not fixed really)
to cope with the newly introduced aliasing problems.

> > See for example OpenSUSE which did this transition correctly:
> >
> >   <https://en.opensuse.org/openSUSE:Usr_merge>
> 
> "The special comments #UsrMerge, #EndUsrMerge will help us to clean up
> the spec files once everything has been moved and we can create a
> general link from /bin to /usr/bin for example. "
> 
> So they want a /bin -> /usr/bin symlink (and the same for the other
> directories) just as in the proposal you call broken...
> 
> Maybe you have misunderstood what SuSE plans to do?

Well, they did a proper transition, and AFAIUI they have not yet
botched the final part.

> Having dpkg track a symlink /bin/${something} and a file
> /usr/bin/${something} will break should /bin be turned into a symlink
> happen.

Only if that symlink is aliasing an existing dpkg owned directory. Which
well, clearly should not be done. If the admin moves the directory
somwehere else (not owned by dpkg), that does *not* create aliasing
problems.

> So there is no nice way to finish the transition.  I'm not sure
> how that would work on RPM; maybe SuSE got stuck with that?  That would
> be another good reason to not follow that way...

If by "finishing the transition" you mean ending up deploying
merged-usr-via-symlinks, well then I guess you missed the entire point
of my mail. It would be pointless to do it by properly moving the
files in the .debs, creating compat symlinks to then botch it at the
end again with the directory symlinks, we might as well botch it from
the beginning. :/

The transition would be finished simply when no (non-required) compat
symlinks are present under the / directories. So we'd remain with just
a few things like /bin/sh and similar required for historical reasons.

> I wouldn't be surprised if that took about as long as the /usr/doc ->
> /usr/share/doc transition.  (If the change process for most simple
> changes like file locations takes 10+ years then I say the process is
> broken...)

As mentioned in my earlier mail, the main difference is that in this
case the move can be fully automated, w/o any initial maintainer
intervention whatsoever. The only thing that requires maintainer
internvation is the analysis and cleanup of the compat symlinks in
the .deb, but that's really not urgent at all in any case.

Regards,
Guillem

Re: merged-/usr-via-symlinks damage control (was Re: usrmerge -- plan B?)

[Guillem Jover]

On Sun, 2019-02-24 at 03:23:09 +0100, Guillem Jover wrote:
> On Tue, 2019-02-19 at 05:49:24 +0100, Guillem Jover wrote:
> > So, as part of damage control I'm going to:
> > 
> >   - include the Build-Tainted-By patches into dpkg 1.19.5.
> 
> Done.
> 
> >   - include a bug-script in dpkg for reportbug to report whether the
> > system has been broken by the merged-/usr-via-symlinks hack.
> 
> Done.
> 
> >   - file a bug on reportbug to request reporting that for all packages.
> 
> Done. <https://bugs.debian.org/923090>
> 
> >   - file a bug on base-installer to request an option to install
> > non-broken systems due to merged-/usr-via-symlinks.
> 
> Done. <https://bugs.debian.org/923091>
> 
> > I'm also pondering whether to implement checks for the broken
> > merged-/usr-via-symlinks within «dpkg --audit», even though I don't
> > really want to, as that would imply hardcoding Debian-specific
> > pathnames in there. :(
> 
> I still have to think about this one. :/
> 
> > And I'm probably going to end up writing a unmerge-usr-via-symlinks
> > script so that people with damaged systems can go back somewhat to a
> > sane state, and to open the possibility for a fully automated migration
> > to a proper and correct merged-/usr w/o all the problems above.
> 
> And I might need to start on this soon enough. :(
> 
> In addition, given that most probably Debian buster will end up
> installing broken systems by default. I might end up also looking into
> generating fixed minimal netinst images or mini netboot images with a
> fixed debootstrap, or I guess just cdebootstrap present which has
> sane behavior. But I would definitely not be able host the artifacts
> for those. :/

Oh, also mmdebstrap was defaulting to the broken merged-/usr-via-symlinks,
for which I filed <https://bugs.debian.org/914915>, which has been fixed
now by disabling it completely! I'm planning on switching all my
debootstrap usage to mmdebstrap anyway because it's superior in any
conceivable way. :) I could also see trying to get that forked d-i use
mmdebstrap, also for its speed.

Thanks,
Guillem

Re: merged-/usr-via-symlinks vs a-different-layout

[Ansgar]

Guillem Jover writes:
> On Tue, 2019-02-19 at 08:54:12 +0100, Ansgar wrote:
>> Guillem Jover writes:
>> > 3) Switching packages to the merged-/usr layout could have been
>> >accomplished automatically via debhelper for a coverage of around
>> >99% (?) of the archive. With something along the lines of:
>> >
>> >  ,---
>> >  D=debian/tmp
>> >  for d in /bin /sbin /lib; do
>> >for p in $(find $D/$d ! -type d); do
>> >  b="${p##$D/}"
>> >  m="$D/usr$b"
>> >  if [ ! -e "$m" ]; then
>> >mkdir -p "$(dirname $m)"
>> >mv "$p" "$m"
>> >ln -s "${m##$D}" "$p"
>> >  fi
>> >done
>> >  done
>> >  `---
>> >
>> >With the property that it would handle gracefully all cases were the
>> >maintainer has checked that no compat symlinks are required and has
>> >then progressively moved the pathname installation to their final
>> >destination under /usr.
>> 
>> That is not merged-/usr, but a different filesystem layout.
>> 
>> So, no, it is not possible to switch packages to merged-/usr this way.
>
> You are still conflating the concept with the deployment. The
> underlaying properties of merging /usr is that the contents for
> directories that are present in both / and /usr get merged into
> /usr.

No, I'm saying that you are proposing yet another different file system
layout.  Which is quite simple to see: the file system would differ.

You just claim it follows similar "ideas" in some way.

I can come up with other variations that move files to /usr too: have
/bin a symlink to /usr/root/bin (some for other directories).  That
would also be a different file system layout which shouldn't be called
"merged-/usr" either.

(That would have no filesystem aliasing between /bin and /usr/bin;
policy has special rules to allow replacing top-level directories with
symlinks; but besides that it is different for no good reason so I don't
think it would be a good idea.)

> See for example OpenSUSE which did this transition correctly:
>
>   <https://en.opensuse.org/openSUSE:Usr_merge>

"The special comments #UsrMerge, #EndUsrMerge will help us to clean up
the spec files once everything has been moved and we can create a
general link from /bin to /usr/bin for example. "

So they want a /bin -> /usr/bin symlink (and the same for the other
directories) just as in the proposal you call broken...

Maybe you have misunderstood what SuSE plans to do?

Having dpkg track a symlink /bin/${something} and a file
/usr/bin/${something} will break should /bin be turned into a symlink
happen.  So there is no nice way to finish the transition.  I'm not sure
how that would work on RPM; maybe SuSE got stuck with that?  That would
be another good reason to not follow that way...

I wouldn't be surprised if that took about as long as the /usr/doc ->
/usr/share/doc transition.  (If the change process for most simple
changes like file locations takes 10+ years then I say the process is
broken...)

Ansgar

Re: merged-/usr-via-symlinks damage control (was Re: usrmerge -- plan B?)

[Guillem Jover]

Hi!

On Tue, 2019-02-19 at 05:49:24 +0100, Guillem Jover wrote:
> So, as part of damage control I'm going to:
> 
>   - include the Build-Tainted-By patches into dpkg 1.19.5.

Done.

>   - include a bug-script in dpkg for reportbug to report whether the
> system has been broken by the merged-/usr-via-symlinks hack.

Done.

>   - file a bug on reportbug to request reporting that for all packages.

Done. <https://bugs.debian.org/923090>

>   - file a bug on base-installer to request an option to install
>     non-broken systems due to merged-/usr-via-symlinks.

Done. <https://bugs.debian.org/923091>

> I'm also pondering whether to implement checks for the broken
> merged-/usr-via-symlinks within «dpkg --audit», even though I don't
> really want to, as that would imply hardcoding Debian-specific
> pathnames in there. :(

I still have to think about this one. :/

> And I'm probably going to end up writing a unmerge-usr-via-symlinks
> script so that people with damaged systems can go back somewhat to a
> sane state, and to open the possibility for a fully automated migration
> to a proper and correct merged-/usr w/o all the problems above.

And I might need to start on this soon enough. :(

In addition, given that most probably Debian buster will end up
installing broken systems by default. I might end up also looking into
generating fixed minimal netinst images or mini netboot images with a
fixed debootstrap, or I guess just cdebootstrap present which has
sane behavior. But I would definitely not be able host the artifacts
for those. :/

Thanks,
Guillem

Re: merged-/usr-via-symlinks vs a-different-layout

[Guillem Jover]

On Tue, 2019-02-19 at 08:54:12 +0100, Ansgar wrote:
> Guillem Jover writes:
> > 3) Switching packages to the merged-/usr layout could have been
> >accomplished automatically via debhelper for a coverage of around
> >99% (?) of the archive. With something along the lines of:
> >
> >  ,---
> >  D=debian/tmp
> >  for d in /bin /sbin /lib; do
> >for p in $(find $D/$d ! -type d); do
> >  b="${p##$D/}"
> >  m="$D/usr$b"
> >  if [ ! -e "$m" ]; then
> >mkdir -p "$(dirname $m)"
> >mv "$p" "$m"
> >ln -s "${m##$D}" "$p"
> >  fi
> >done
> >  done
> >  `---
> >
> >With the property that it would handle gracefully all cases were the
> >maintainer has checked that no compat symlinks are required and has
> >then progressively moved the pathname installation to their final
> >destination under /usr.
> 
> That is not merged-/usr, but a different filesystem layout.
> 
> So, no, it is not possible to switch packages to merged-/usr this way.

You are still conflating the concept with the deployment. The
underlaying properties of merging /usr is that the contents for
directories that are present in both / and /usr get merged into
/usr.

See for example OpenSUSE which did this transition correctly:

  <https://en.opensuse.org/openSUSE:Usr_merge>

> > 4) Due to having to support the broken merged-/usr-via-symlinks
> >deployment, when we want to move the contents of the binary
> >packages to the merged-/usr layout, we require now to include tons
> >of logic in (probably new) maintainer scripts, when we have been
> >trying to remove them altogether. :( With even more files untracked
> >by dpkg itself, bypassing the packaging system even more, when the
> >compat symlinks could have been shipped in the binary packages.
> 
> As far as I know maintainer scripts are only required for moving files
> from / to /usr when (a) a compat symlink is required, and (b) only when
> both merged-/usr and non-merged-/usr is supported.

I guess you are implying that we should start forcing and requiring
the broken deployment into all Debian systems… if that ever happens
I'm personally going to use any local technical means to avoid such
breakage to damage any of my systems…

Regards,
Guillem

Re: merged-/usr-via-symlinks vs a-different-layout

[Ansgar]

Guillem Jover writes:
> 3) Switching packages to the merged-/usr layout could have been
>accomplished automatically via debhelper for a coverage of around
>99% (?) of the archive. With something along the lines of:
>
>  ,---
>  D=debian/tmp
>  for d in /bin /sbin /lib; do
>for p in $(find $D/$d ! -type d); do
>  b="${p##$D/}"
>  m="$D/usr$b"
>  if [ ! -e "$m" ]; then
>mkdir -p "$(dirname $m)"
>mv "$p" "$m"
>ln -s "${m##$D}" "$p"
>  fi
>done
>  done
>  `---
>
>With the property that it would handle gracefully all cases were the
>maintainer has checked that no compat symlinks are required and has
>then progressively moved the pathname installation to their final
>    destination under /usr.

That is not merged-/usr, but a different filesystem layout.

So, no, it is not possible to switch packages to merged-/usr this way.

> 4) Due to having to support the broken merged-/usr-via-symlinks
>deployment, when we want to move the contents of the binary
>packages to the merged-/usr layout, we require now to include tons
>of logic in (probably new) maintainer scripts, when we have been
>trying to remove them altogether. :( With even more files untracked
>by dpkg itself, bypassing the packaging system even more, when the
>compat symlinks could have been shipped in the binary packages.

As far as I know maintainer scripts are only required for moving files
from / to /usr when (a) a compat symlink is required, and (b) only when
both merged-/usr and non-merged-/usr is supported.

Ansgar

merged-/usr-via-symlinks damage control (was Re: usrmerge -- plan B?)

[Guillem Jover]

Hi!

On Tue, 2018-11-20 at 22:16:17 +0100, Adam Borowski wrote:
> Thus, it seems to me that the plan A for usrmerge has serious downsides for
> dubious benefits.  What about the plan B I described above?

So, people still seem to be conflating merged-/usr (the filesystem
layout) with the different ways to deploy it. Personally I do agree
that merged-/usr has benefits, and that's why I've f.ex. been switching
the shared library packages I maintain to do a proper and correct switch
by installing their files in /usr/lib instead of /lib.

The underlaying problem with the merged-/usr-via-symlinks is not
really that it has generated bugs, many transitions we perform incur
those, for the better. The problem is that it has generated those when
it was really not necessary in the first place, has made things
unnecessarily more complicated for everyone, and it's a terrible hack
trying to reap "quick" benefits at the cost of everyhing else, with
long lasting consequences even after a full migration to /usr would
have been finished. And here's why:

1) The merged-/usr-via-symlinks deployment method used by both
   debootstrap and usrmerge, means that those systems will get
   permanent filesystem aliasing problems, forever. Even when all
   files might have been moved to their /usr counterparts in the
   packages! This is due to the fact that different pathnames can
   end up pointing (before any canonicalization!) to the same dentry.

   This does not only affect dpkg (dpkg, dpkg-divert, dpkg-trigger,
   etc), and update-alternatives (in a worse way), but any program
   that uses pathanmes in the filesystem as keys in databases f.ex.

2) It bypasses the packaging system understanding of what is on the
   filesystem and creates mismatches between what's on binary packages
   and what's on disk.

3) Switching packages to the merged-/usr layout could have been
   accomplished automatically via debhelper for a coverage of around
   99% (?) of the archive. With something along the lines of:

 ,---
 D=debian/tmp
 for d in /bin /sbin /lib; do
   for p in $(find $D/$d ! -type d); do
 b="${p##$D/}"
 m="$D/usr$b"
 if [ ! -e "$m" ]; then
   mkdir -p "$(dirname $m)"
   mv "$p" "$m"
   ln -s "${m##$D}" "$p"
 fi
   done
 done
 `---

   With the property that it would handle gracefully all cases were the
   maintainer has checked that no compat symlinks are required and has
   then progressively moved the pathname installation to their final
   destination under /usr.

4) Due to having to support the broken merged-/usr-via-symlinks
   deployment, when we want to move the contents of the binary
   packages to the merged-/usr layout, we require now to include tons
   of logic in (probably new) maintainer scripts, when we have been
   trying to remove them altogether. :( With even more files untracked
   by dpkg itself, bypassing the packaging system even more, when the
   compat symlinks could have been shipped in the binary packages.

5) Most new installations will not even benefit from this hacky and
   rushed deployment, as long as they do not use a separate parition
   for /usr!

6) The merged-/usr-via-symlinks deployment hack is irreversible right
   now.

This is all really terrible engineering. :(


So, as part of damage control I'm going to:

  - include the Build-Tainted-By patches into dpkg 1.19.5.
  - include a bug-script in dpkg for reportbug to report whether the
system has been broken by the merged-/usr-via-symlinks hack.
  - file a bug on reportbug to request reporting that for all packages.
  - file a bug on base-installer to request an option to install
non-broken systems due to merged-/usr-via-symlinks.

I'm also pondering whether to implement checks for the broken
merged-/usr-via-symlinks within «dpkg --audit», even though I don't
really want to, as that would imply hardcoding Debian-specific
pathnames in there. :(

And I'm probably going to end up writing a unmerge-usr-via-symlinks
script so that people with damaged systems can go back somewhat to a
sane state, and to open the possibility for a fully automated migration
to a proper and correct merged-/usr w/o all the problems above.

Thanks,
Guillem

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

[Ian Jackson]

Package: debootstrap
Version: debootstrap/1.0.110
Severity: serious

Merged /usr is now the default in buster.  As discussed on
debian-devel, however, binary packages built on a merged-usr system
are not installable on a non-merged-usr system.  I think we would like
ad hoc builds of packages from one buster machine to be installable on
other buster machines.  That is not compatible with the current
approach.

This was an unanticipated problem.  The discussion on -devel has not
reached a consensus on a way forward, and there is no transition plan.

Accordingly, please revert this change for buster.

IMO this revert should be done quickly, to minimise the number of
installs which will generate broken packages.  If you do not agree
with my proposal, then I still think we should revert the change in
sid/buster while the matter is discussed.

This affects stretch-backports too, but I think it will be most
convenient to file a separate bug for that.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#914898: debootstrap, stretch-backports: Please disabled merged /usr by default

[Ian Jackson]

Package: debootstrap
Version: debootstrap/1.0.110~bpo9+1
Severity: serious

In #914208 Simon McVittie writes:
> [merge-/usr] is now the default in stretch-backports' debootstrap

As discussed on debian-devel, however, binary packages built on a
merged-usr system are not installable on a non-merged-usr system.
Obviously we would like ad hoc builds of packages from one stretch
machine to be installable on other stretch machines.

I do not see any way in which this could be resolved for stretch.
Accordingly, please urgently revert this change for stretch-backports.

Ian.

(I have CC'd debian-release@lists because this seems like it wants the
attention of the stable release team.  I wasn't able to find a
separate contact address for the stable release team here
  https://www.debian.org/intro/organization
and I have a vague memory that this is somehow the same list.  Please
redirect me if I am wrong.)

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Bug#843073: dpkg-shlibdeps fix for merged /usr

[Guillem Jover]

On Mon, 2016-12-12 at 04:26:20 +0100, Marco d'Itri wrote:
> On Nov 21, Guillem Jover  wrote:
> > First I have to go over a list of queued pending items and then I'll
> > get to this during this week. I have not yet reviewed the patches (in
> > part because I didn't do much Debian stuff last week due to lack of
> > motivation after an unpleasant interaction precisely due to this
> > issue, and TBH it has become one of those energey drainers), there's
> > a pending run in rebootstrap by Helmut (which is now waiting for a
> > gixed gcc), and then I need to write a mail summary of the current
> > situation and implications.

> Do you have any updates about reviewing this patch?

Now that Helmut has done an initial successful build with rebootstrap,
I'm planning on reviewing and merging this after having sent that summary
mail, either for .16 or .17, which I'd like to upload in quick succession,
starting this week.

Thanks,
Guillem

Re: Bug#843073: dpkg-shlibdeps fix for merged /usr

[Marco d'Itri]

On Nov 21, Guillem Jover  wrote:

> First I have to go over a list of queued pending items and then I'll
> get to this during this week. I have not yet reviewed the patches (in
> part because I didn't do much Debian stuff last week due to lack of
> motivation after an unpleasant interaction precisely due to this
> issue, and TBH it has become one of those energey drainers), there's
> a pending run in rebootstrap by Helmut (which is now waiting for a
> gixed gcc), and then I need to write a mail summary of the current
> situation and implications.
Do you have any updates about reviewing this patch?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Issues when building armhf packages in sid chroot with merged-usr

[Marco d'Itri]

On Nov 10, Uwe Kleine-König  wrote:

> I tried to build the experimental linux package on an armhf machine
> using sbuild. It failed (after 7 hours, sigh) with:
This looks like #843073.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Issues when building armhf packages in sid chroot with merged-usr

[Uwe Kleine-König]

Hello,

I tried to build the experimental linux package on an armhf machine
using sbuild. It failed (after 7 hours, sigh) with:

dpkg-shlibdeps: error: no dependency information found for 
/usr/lib/ld-linux-armhf.so.3 (used by 
debian/linux-kbuild-4.9/usr/lib/linux-kbuild-4.9/scripts/pnmtologo)

I can reproduce the same problem with an easier package (memtool) from
unstable which already built fine on the buildd. On abel.d.o schroot -c
sid doesn't result in a system with /lib being a symlink to /usr/lib, so
I guess this still builds fine.

Maybe this is even not arm specific?

Best regards
Uwe


signature.asc
Description: PGP signature

Re: Support for merged-/usr now in debootstrap; default for stretch?

[Ansgar Burchardt]

On Tue, 2016-09-27 at 15:42 +0500, Andrey Rahmatullin wrote:
> On Tue, Sep 13, 2016 at 10:36:58PM +0200, Ansgar Burchardt wrote:
> > 
> > debootstrap in unstable can now install with merged-/usr, that is
> > with
> > /bin, /sbin, /lib* being symlinks to their counterpart in
> > /usr.  Run
> > 
> >   debootstrap --merged-usr testing .../testing http://deb.debian.or
> > g/debian
> > 
> > to give it a try.
> usrmerge Conflicts: zsh << experimental, does this apply to
> debootstrap
> solution too?

The `Conflicts:` in usrmerge is too strict, see [1].

Ansgar

  [1] https://bugs.debian.org/824205

Re: Support for merged-/usr now in debootstrap; default for stretch?

[Andrey Rahmatullin]

On Tue, Sep 13, 2016 at 10:36:58PM +0200, Ansgar Burchardt wrote:
> debootstrap in unstable can now install with merged-/usr, that is with
> /bin, /sbin, /lib* being symlinks to their counterpart in /usr.  Run
> 
>   debootstrap --merged-usr testing .../testing http://deb.debian.org/debian
> 
> to give it a try.
usrmerge Conflicts: zsh << experimental, does this apply to debootstrap
solution too?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Support for merged-/usr now in debootstrap; default for stretch?

[Marco d'Itri]

On Sep 14, Felipe Sateler  wrote:

> I agree that merging /usr is a good thing to do. We should default to 
> that, and at some point force the merge somehow (via the usrmerge package?
To be fair, I have implemented this as a switch only because I expected 
that somebody would have complained about the lack of an opt-out 
mechanism.
Since merged-/usr has significant benefits and is the scheme used 
RHEL/Centos/Fedora I think that it should be the default for us as well.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Support for merged-/usr now in debootstrap; default for stretch?

[Marco d'Itri]

On Sep 15, Adam Borowski  wrote:

> I think it would be worthwhile to split up and move parts of /var as well. 
This is out of scope for this thread, so please let's discuss your 
proposals at a different time.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Support for merged-/usr now in debootstrap; default for stretch?

[Adam Borowski]

On Wed, Sep 14, 2016 at 05:08:18PM +0200, Michael Biebl wrote:
> Am 14.09.2016 um 16:50 schrieb Pierre Chifflier:
> > Except that breaks having different mount points, which is useful to
> > enforce different mount options (my /usr is nodev,ro).
> > Does this mean this cannot be supported anymore ? It would be a step
> > backward, security-speaking, if split /usr does not work at all.
> 
> That's still possible, it would be an improvement even, as now all of
> your system would be in /usr and would be confined by your mount
> options. Atm you have parts in / and parts in /usr and your mount
> options only apply to the bits in /usr.
> A fully read-only system is actually much simpler with the merged-usr setup.

I think it would be worthwhile to split up and move parts of /var as well. 
It is a big mess of distinct stuff:
* parts of packaging: /var/lib/dpkg (especially info/) or files generated at
  install/reconfigure time.  These could probably be stored under /usr as
  they are modified at the same time.
* user data: /var/www, /var/lib/mysql, /var/mail
* volatile not-for-backup cache: /var/cache
* stuff that would be in /var/cache if not for some detail:
  /var/lib/apt/lists (not in /var/cache only because non-root has no way to
  recover from deletion)
* temporary scratch space (not in /tmp so others can't mess with it)
* various state, both system and user
* managed config files
* logs

The current split comes from '80s use cases, when /usr was meant to be
mounted over network to enable sharing between machines as files there took
entire MEGABYTES of space.  Thus, the split became:
* /bin, /sbin and co: needed to mount the rest
* /usr: shareable over the net
* /var: not easily shareable (deduplication and CoW wasn't invented yet)

None of this makes sense anymore.  Even smallest ARMs you can install Debian
on without heavy changes have since moved to multi-gigabyte storage, so if
you have local media at all (ie, not network boot), you can as well have
/usr together with the rest.  And a decade ago, when Nokia tried tiny NAND
plus big eMMC, the /-vs-/usr split proved too hard to adapt for their use
case so they ended up with /usr on NAND that included lots of symlinks to
/opt.

And when sharing storage between machines, there's no need to micromanage
common files anymore -- just give every system its own logical filesystem
and use one of CoW/deduplication schemes.

So what are modern use cases?
* security: want ro for as much as possible
* backup retention: want to know what to exclude, what to store "just for
  restore upon disk failure" and what to store long time
* snapshots

Current FHS makes the last part especially bad, and requires either lots of
symlinks or lots of waste.  Generally, we want two separate areas of
snapshots:
* the system.  Especially vital for unstable, but useful for any system you
  might make changes to from time to time.  Lets you roll back and forward
  to any prior state, to recover from breakages, test experimental stuff,
  etc.
* user data.  In case you made a bad edit a week ago, etc.  No real point
  for wholesale rollback but unlike plain backups, having all of this as
  greppable/etc files is handy.

Especially for system backups, you want them complete in one piece because
of interdependencies.  Trying to mix /usr /etc and system parts of /var from
different points of time is likely to result in breakage.  Yet if you roll
back the whole of /var you lose parts of user data stored there.


Meow!
-- 
Second "wet cat laying down on a powered-on box-less SoC on the desk" close
shave in a week.  Protect your ARMs, folks!

Re: Support for merged-/usr now in debootstrap; default for stretch?

[Marco d'Itri]

On Sep 14, Ansgar Burchardt  wrote:

> One can also test installations using d-i.  The images from [1] already
Just to be clear: merged-/usr can be tested on an existing system by 
installing the usrmerge package.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Support for merged-/usr now in debootstrap; default for stretch?

[Michael Biebl]

Am 14.09.2016 um 16:50 schrieb Pierre Chifflier:
> Except that breaks having different mount points, which is useful to
> enforce different mount options (my /usr is nodev,ro).
> Does this mean this cannot be supported anymore ? It would be a step
> backward, security-speaking, if split /usr does not work at all.

That's still possible, it would be an improvement even, as now all of
your system would be in /usr and would be confined by your mount
options. Atm you have parts in / and parts in /usr and your mount
options only apply to the bits in /usr.
A fully read-only system is actually much simpler with the merged-usr setup.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature