Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.devel > #100738 > unrolled thread
| Started by | Thorsten Glaser <tg@debian.org> |
|---|---|
| First post | 2021-07-14 22:10 +0200 |
| Last post | 2021-07-18 19:20 +0200 |
| Articles | 20 on this page of 246 — 53 participants |
Back to article view | Back to linux.debian.devel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
merged /usr considered harmful (was Re: Bits from the Technical Committee) Thorsten Glaser <tg@debian.org> - 2021-07-14 22:10 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Guillem Jover <guillem@debian.org> - 2021-07-14 23:50 +0200
Re: merged /usr considered harmful Thorsten Glaser <tg@debian.org> - 2021-07-15 05:20 +0200
Re: merged /usr considered harmful Thomas Goirand <zigo@debian.org> - 2021-07-16 10:00 +0200
Re: merged /usr considered harmful Pierre-Elliott Bécue <peb@debian.org> - 2021-07-16 13:10 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Sean Whitton <spwhitton@spwhitton.name> - 2021-07-15 09:10 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Jonathan Carter <jcc@debian.org> - 2021-07-15 10:00 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Marc Haber <mh+debian-devel@zugschlus.de> - 2021-07-15 10:50 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Jonathan Carter <jcc@debian.org> - 2021-07-15 11:40 +0200
Re: merged /usr considered harmful Thorsten Glaser <tg@debian.org> - 2021-07-16 04:00 +0200
Re: merged /usr considered harmful Marc Haber <mh+debian-devel@zugschlus.de> - 2021-07-16 09:20 +0200
Re: merged /usr considered harmful The Wanderer <wanderer@fastmail.fm> - 2021-07-16 10:40 +0200
endless discussion considered harmful Philip Hands <phil@hands.com> - 2021-07-16 12:40 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Sean Whitton <spwhitton@spwhitton.name> - 2021-07-15 20:10 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Luca Boccassi <bluca@debian.org> - 2021-07-15 11:20 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Magissia <debianlist@magissia.com> - 2021-07-16 13:50 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Helmut Grohne <helmut@subdivi.de> - 2021-07-18 23:00 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Guillem Jover <guillem@debian.org> - 2021-07-19 03:40 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Marc Haber <mh+debian-devel@zugschlus.de> - 2021-07-19 07:20 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Gunnar Wolf <gwolf@debian.org> - 2021-07-19 08:40 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Gunnar Wolf <gwolf@debian.org> - 2021-07-19 09:00 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Stephan Lachnit <stephanlachnit@debian.org> - 2021-07-19 11:40 +0200
Re: merged /usr Simon McVittie <smcv@debian.org> - 2021-07-19 13:00 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Michael Biebl <biebl@debian.org> - 2021-07-19 15:30 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Johannes Schauer Marin Rodrigues <josch@debian.org> - 2021-07-19 16:50 +0200
Re: merged /usr Simon McVittie <smcv@debian.org> - 2021-07-19 19:50 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Niels Thykier <niels@thykier.net> - 2021-07-20 08:20 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Guillem Jover <guillem@debian.org> - 2021-07-20 11:40 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Guillem Jover <guillem@debian.org> - 2021-07-20 12:30 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Andreas Metzler <ametzler@bebt.de> - 2021-07-20 14:00 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Svante Signell <svante.signell@gmail.com> - 2021-07-20 14:50 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-07-20 21:40 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Svante Signell <svante.signell@gmail.com> - 2021-07-20 23:20 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Holger Levsen <holger@layer-acht.org> - 2021-07-21 00:00 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Svante Signell <svante.signell@gmail.com> - 2021-07-21 00:10 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Holger Levsen <holger@layer-acht.org> - 2021-07-21 00:30 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-07-21 03:20 +0200
Re: not actually anything to do with merged-/usr any more Simon McVittie <smcv@debian.org> - 2021-07-21 10:30 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-07-21 03:20 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-07-21 03:20 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Brian Thompson <brian@hashvault.io> - 2021-07-21 04:10 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-07-21 04:40 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Marc Haber <mh+debian-devel@zugschlus.de> - 2021-07-21 08:20 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Marc Haber <mh+debian-devel@zugschlus.de> - 2021-07-20 21:40 +0200
a little productivity on the side (was Re: merged /usr considered harmful) Thorsten Glaser <tg@debian.org> - 2021-07-22 04:00 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Guillem Jover <guillem@debian.org> - 2021-07-20 11:20 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Wouter Verhelst <wouter@debian.org> - 2021-07-22 16:00 +0200
Re: merged /usr Simon McVittie <smcv@debian.org> - 2021-07-22 16:30 +0200
Re: merged /usr Wouter Verhelst <wouter@debian.org> - 2021-07-27 12:50 +0200
Re: merged /usr Andreas Metzler <ametzler@bebt.de> - 2021-07-27 14:20 +0200
Re: merged /usr Wouter Verhelst <wouter@debian.org> - 2021-07-27 15:30 +0200
Re: merged /usr Andrey Rahmatullin <wrar@debian.org> - 2021-07-27 16:00 +0200
Re: merged /usr Wouter Verhelst <wouter@debian.org> - 2021-07-27 17:10 +0200
Re: merged /usr Sam Hartman <hartmans@debian.org> - 2021-07-27 17:30 +0200
Re: merged /usr Steve Cotton <steve@octalot.at> - 2021-07-28 02:40 +0200
Re: merged /usr Andreas Metzler <ametzler@bebt.de> - 2021-07-27 17:40 +0200
Re: merged /usr Guillem Jover <guillem@debian.org> - 2021-07-27 14:30 +0200
Re: merged /usr Simon Richter <sjr@debian.org> - 2021-07-27 16:40 +0200
Re: merged /usr Guillem Jover <guillem@debian.org> - 2021-07-27 17:10 +0200
Re: merged /usr Calum McConnell <calumlikesapplepie@gmail.com> - 2021-07-27 19:30 +0200
Re: merged /usr Simon Richter <sjr@debian.org> - 2021-07-28 16:40 +0200
Re: merged /usr Guillem Jover <guillem@debian.org> - 2021-08-13 02:00 +0200
Re: merged /usr Marco d'Itri <md@Linux.IT> - 2021-08-13 08:00 +0200
Re: merged /usr Guillem Jover <guillem@debian.org> - 2021-08-13 11:00 +0200
Re: merged /usr Marco d'Itri <md@Linux.IT> - 2021-08-13 17:30 +0200
Re: merged /usr Luca Boccassi <bluca@debian.org> - 2021-08-13 11:20 +0200
Re: merged /usr David Kalnischkies <david@kalnischkies.de> - 2021-08-14 14:40 +0200
Re: merged /usr Luca Boccassi <bluca@debian.org> - 2021-08-14 15:10 +0200
Re: merged /usr David Kalnischkies <david@kalnischkies.de> - 2021-08-14 16:00 +0200
Re: merged /usr Simon McVittie <smcv@debian.org> - 2021-08-14 15:30 +0200
Re: merged /usr David Kalnischkies <david@kalnischkies.de> - 2021-08-14 17:00 +0200
Re: merged /usr Simon McVittie <smcv@debian.org> - 2021-08-15 01:20 +0200
Re: merged /usr David Kalnischkies <david@kalnischkies.de> - 2021-08-15 12:00 +0200
Re: merged /usr Simon McVittie <smcv@debian.org> - 2021-08-15 19:00 +0200
Re: merged /usr Marco d'Itri <md@Linux.IT> - 2021-08-16 01:10 +0200
Re: merged /usr David Kalnischkies <david@kalnischkies.de> - 2021-08-16 11:50 +0200
Re: merged /usr Luca Boccassi <bluca@debian.org> - 2021-08-16 14:40 +0200
Re: merged /usr Marco d'Itri <md@Linux.IT> - 2021-08-16 15:20 +0200
Re: merged /usr David Kalnischkies <david@kalnischkies.de> - 2021-08-17 12:10 +0200
Re: merged /usr Luca Boccassi <bluca@debian.org> - 2021-08-17 12:30 +0200
A summary of where I think we are on the technical side of the merged /usr discussion Sam Hartman <hartmans@debian.org> - 2021-08-17 16:10 +0200
Re: A summary of where I think we are on the technical side of the merged /usr discussion Simon McVittie <smcv@debian.org> - 2021-08-17 18:20 +0200
Re: A summary of where I think we are on the technical side of the merged /usr discussion "Theodore Ts'o" <tytso@mit.edu> - 2021-08-17 19:00 +0200
Re: A summary of where I think we are on the technical side of the merged /usr discussion Simon McVittie <smcv@debian.org> - 2021-08-17 20:10 +0200
Re: A summary of where I think we are on the technical side of the merged /usr discussion Simon Richter <sjr@debian.org> - 2021-08-17 21:20 +0200
Re: A summary of where I think we are on the technical side of the merged /usr discussion Luca Boccassi <bluca@debian.org> - 2021-08-18 00:30 +0200
Re: A summary of where I think we are on the technical side of the merged /usr discussion Simon Richter <sjr@debian.org> - 2021-08-18 10:50 +0200
Re: A summary of where I think we are on the technical side of the merged /usr discussion Luca Boccassi <bluca@debian.org> - 2021-08-18 11:50 +0200
Re: A summary of where I think we are on the technical side of the merged /usr discussion "Theodore Ts'o" <tytso@mit.edu> - 2021-08-18 05:30 +0200
Re: merged /usr Simon McVittie <smcv@debian.org> - 2021-08-18 11:20 +0200
Re: merged /usr Marco d'Itri <md@Linux.IT> - 2021-08-18 18:40 +0200
Re: A summary of where I think we are on the technical side of the merged /usr discussion Helmut Grohne <helmut@subdivi.de> - 2021-08-19 10:20 +0200
Re: merged /usr vs. symlink farms Simon McVittie <smcv@debian.org> - 2021-08-19 12:20 +0200
Re: merged /usr vs. symlink farms "Theodore Ts'o" <tytso@mit.edu> - 2021-08-19 16:50 +0200
Re: merged /usr vs. symlink farms Simon Richter <sjr@debian.org> - 2021-08-19 22:50 +0200
Re: merged /usr vs. symlink farms "Theodore Ts'o" <tytso@mit.edu> - 2021-08-20 02:00 +0200
Re: merged /usr vs. symlink farms Craig Small <csmall@debian.org> - 2021-08-20 02:40 +0200
Re: merged /usr vs. symlink farms Luca Boccassi <bluca@debian.org> - 2021-08-20 12:30 +0200
Re: merged /usr vs. symlink farms Philip Hands <phil@hands.com> - 2021-08-20 15:10 +0200
Re: merged /usr vs. symlink farms Wouter Verhelst <wouter@debian.org> - 2021-08-21 10:30 +0200
Re: merged /usr vs. symlink farms Luca Boccassi <bluca@debian.org> - 2021-08-21 15:50 +0200
Re: merged /usr vs. symlink farms Wouter Verhelst <wouter@debian.org> - 2021-08-21 16:30 +0200
Re: merged /usr vs. symlink farms Luca Boccassi <bluca@debian.org> - 2021-08-21 19:50 +0200
Re: merged /usr vs. symlink farms Colin Watson <cjwatson@debian.org> - 2021-08-21 21:50 +0200
Re: merged /usr vs. symlink farms Luca Boccassi <bluca@debian.org> - 2021-08-22 12:00 +0200
Re: merged /usr vs. symlink farms Guillem Jover <guillem@debian.org> - 2021-08-21 23:00 +0200
Re: merged /usr vs. symlink farms Luca Boccassi <bluca@debian.org> - 2021-08-22 12:30 +0200
Re: merged /usr vs. symlink farms Steve Cotton <steve@octalot.at> - 2021-08-22 13:10 +0200
Re: merged /usr vs. symlink farms Luca Boccassi <bluca@debian.org> - 2021-08-22 23:30 +0200
Re: merged /usr vs. symlink farms Guillem Jover <guillem@debian.org> - 2021-11-12 05:00 +0100
Re: merged /usr vs. symlink farms Luca Boccassi <bluca@debian.org> - 2021-11-12 12:00 +0100
Re: merged /usr vs. symlink farms Simon Richter <sjr@debian.org> - 2021-08-22 02:20 +0200
Re: merged /usr vs. symlink farms "Theodore Ts'o" <tytso@mit.edu> - 2021-08-22 05:20 +0200
Re: merged /usr vs. symlink farms Luca Boccassi <bluca@debian.org> - 2021-08-22 12:30 +0200
Re: merged /usr vs. symlink farms Russ Allbery <rra@debian.org> - 2021-08-22 16:50 +0200
Re: merged /usr vs. symlink farms Luca Boccassi <bluca@debian.org> - 2021-08-22 23:30 +0200
Re: merged /usr vs. symlink farms Russ Allbery <rra@debian.org> - 2021-08-23 04:20 +0200
Re: merged /usr vs. symlink farms Luca Boccassi <bluca@debian.org> - 2021-08-23 15:50 +0200
Re: merged /usr vs. symlink farms Russ Allbery <rra@debian.org> - 2021-08-23 17:30 +0200
Re: merged /usr vs. symlink farms Simon Richter <sjr@debian.org> - 2021-08-23 22:10 +0200
Re: merged /usr vs. symlink farms Russ Allbery <rra@debian.org> - 2021-08-23 22:50 +0200
Re: merged /usr vs. symlink farms Ansgar <ansgar@43-1.org> - 2021-08-23 23:20 +0200
Re: merged /usr vs. symlink farms Russ Allbery <rra@debian.org> - 2021-08-23 23:30 +0200
Debhelper and /lib/systemd vs /usr/lib/systemd Sam Hartman <hartmans@debian.org> - 2021-08-24 01:30 +0200
Re: Debhelper and /lib/systemd vs /usr/lib/systemd Russ Allbery <rra@debian.org> - 2021-08-24 02:00 +0200
Re: Debhelper and /lib/systemd vs /usr/lib/systemd Niels Thykier <niels@thykier.net> - 2021-08-25 20:40 +0200
Re: Debhelper and /lib/systemd vs /usr/lib/systemd Sam Hartman <hartmans@debian.org> - 2021-08-25 22:10 +0200
Re: Debhelper and /lib/systemd vs /usr/lib/systemd Simon Richter <sjr@debian.org> - 2021-08-25 23:10 +0200
Re: Debhelper and /lib/systemd vs /usr/lib/systemd Niels Thykier <niels@thykier.net> - 2021-08-25 23:30 +0200
Re: Debhelper and /lib/systemd vs /usr/lib/systemd Andreas Metzler <ametzler@bebt.de> - 2021-08-26 19:40 +0200
Re: Debhelper and /lib/systemd vs /usr/lib/systemd Niels Thykier <niels@thykier.net> - 2021-08-25 23:20 +0200
Re: Debhelper and /lib/systemd vs /usr/lib/systemd Sam Hartman <hartmans@debian.org> - 2021-08-26 18:00 +0200
Re: Debhelper and /lib/systemd vs /usr/lib/systemd Niels Thykier <niels@thykier.net> - 2021-08-26 19:50 +0200
Re: merged /usr vs. symlink farms Wouter Verhelst <wouter@debian.org> - 2021-08-25 18:10 +0200
Re: merged /usr vs. symlink farms Russ Allbery <rra@debian.org> - 2021-08-25 19:00 +0200
Re: merged /usr vs. symlink farms Guillem Jover <guillem@debian.org> - 2021-08-25 20:10 +0200
Re: merged /usr vs. symlink farms Russ Allbery <rra@debian.org> - 2021-08-25 22:30 +0200
Re: merged /usr vs. symlink farms Wouter Verhelst <wouter@debian.org> - 2021-08-25 21:50 +0200
Re: merged /usr vs. symlink farms Simon Richter <sjr@debian.org> - 2021-08-25 22:00 +0200
Re: merged /usr vs. symlink farms Russ Allbery <rra@debian.org> - 2021-08-25 22:10 +0200
Re: merged /usr vs. symlink farms Simon Richter <sjr@debian.org> - 2021-08-22 17:10 +0200
Re: merged /usr vs. symlink farms Simon Richter <sjr@debian.org> - 2021-08-22 21:10 +0200
Making the dpkg database correspond with reality (Was Re: merged /usr vs. symlink farms) "Theodore Ts'o" <tytso@mit.edu> - 2021-08-24 02:50 +0200
Re: Making the dpkg database correspond with reality (Was Re: merged /usr vs. symlink farms) Timo Röhling <roehling@debian.org> - 2021-08-24 08:50 +0200
Re: Making the dpkg database correspond with reality (Was Re: merged /usr vs. symlink farms) Simon Richter <sjr@debian.org> - 2021-08-24 12:00 +0200
Re: Making the dpkg database correspond with reality (Was Re: merged /usr vs. symlink farms) "Theodore Ts'o" <tytso@mit.edu> - 2021-08-24 16:50 +0200
Re: Making the dpkg database correspond with reality (Was Re: merged /usr vs. symlink farms) Simon McVittie <smcv@debian.org> - 2021-08-24 20:00 +0200
Re: merged /usr vs. symlink farms Sam Hartman <hartmans@debian.org> - 2021-08-23 16:20 +0200
Re: merged /usr vs. symlink farms Timo Röhling <roehling@debian.org> - 2021-08-22 12:20 +0200
Re: merged /usr vs. symlink farms "Theodore Ts'o" <tytso@mit.edu> - 2021-08-21 18:50 +0200
Re: merged /usr vs. symlink farms David Kalnischkies <david@kalnischkies.de> - 2021-08-22 12:30 +0200
Re: merged /usr vs. symlink farms "Theodore Ts'o" <tytso@mit.edu> - 2021-08-23 01:10 +0200
Re: merged /usr vs. symlink farms gregor herrmann <gregoa@debian.org> - 2021-08-23 02:50 +0200
Re: merged /usr vs. symlink farms Sam Hartman <hartmans@debian.org> - 2021-08-20 16:00 +0200
Re: merged /usr vs. symlink farms "Theodore Ts'o" <tytso@mit.edu> - 2021-08-20 20:00 +0200
Re: merged /usr vs. symlink farms Simon Richter <sjr@debian.org> - 2021-08-20 23:20 +0200
Re: merged /usr vs. symlink farms Luca Boccassi <bluca@debian.org> - 2021-08-21 15:40 +0200
Re: merged /usr vs. symlink farms Sam Hartman <hartmans@suchdamage.org> - 2021-08-23 16:40 +0200
Re: merged /usr vs. symlink farms Aurelien Jarno <aurelien@aurel32.net> - 2021-08-25 21:40 +0200
Re: merged /usr vs. symlink farms Danilo Santos <santosdanilo2013@gmail.com> - 2021-08-26 08:20 +0200
Re: merged /usr vs. symlink farms Guillem Jover <guillem@debian.org> - 2021-08-22 00:20 +0200
Re: merged /usr vs. symlink farms Andreas Metzler <ametzler@bebt.de> - 2021-08-22 09:20 +0200
Re: merged /usr vs. symlink farms Guillem Jover <guillem@debian.org> - 2021-08-26 03:00 +0200
Re: merged /usr vs. symlink farms Marco d'Itri <md@Linux.IT> - 2021-08-26 09:10 +0200
Re: merged /usr vs. symlink farms Simon Richter <sjr@debian.org> - 2021-08-26 12:20 +0200
Re: merged /usr vs. symlink farms Luca Boccassi <bluca@debian.org> - 2021-08-26 13:20 +0200
Re: merged /usr vs. symlink farms Philip Hands <phil@hands.com> - 2021-08-26 14:00 +0200
Re: merged /usr vs. symlink farms Luca Boccassi <bluca@debian.org> - 2021-08-26 14:20 +0200
Re: merged /usr vs. symlink farms Simon Richter <sjr@debian.org> - 2021-08-26 15:00 +0200
Re: merged /usr vs. symlink farms Timo Röhling <roehling@debian.org> - 2021-08-26 15:40 +0200
Re: merged /usr vs. symlink farms Sam Hartman <hartmans@debian.org> - 2021-08-26 17:00 +0200
Re: merged /usr vs. symlink farms Timo Röhling <roehling@debian.org> - 2021-08-26 17:40 +0200
Re: merged /usr vs. symlink farms Andreas Metzler <ametzler@bebt.de> - 2021-08-26 19:30 +0200
Re: merged /usr vs. symlink farms Luca Boccassi <bluca@debian.org> - 2021-08-26 16:00 +0200
next steps after usrunmess Phil Morrell <debian@emorrp1.name> - 2021-08-27 04:50 +0200
Re: next steps after usrunmess "Theodore Ts'o" <tytso@mit.edu> - 2021-08-27 17:30 +0200
Re: next steps after usrunmess Bastien ROUCARIES <roucaries.bastien@gmail.com> - 2021-08-27 20:00 +0200
Re: next steps after usrmerge "Theodore Ts'o" <tytso@mit.edu> - 2021-08-27 20:10 +0200
Re: next steps after usrunmess Phil Morrell <debian@emorrp1.name> - 2021-08-27 20:40 +0200
Re: next steps after usrunmess Bastien ROUCARIES <roucaries.bastien@gmail.com> - 2021-08-27 21:40 +0200
Re: next steps after usrunmess Richard Laager <rlaager@debian.org> - 2021-08-27 21:20 +0200
Re: merged-/usr vs. partially-symlink-farmed-root Ansgar <ansgar@43-1.org> - 2021-08-22 11:10 +0200
Re: merged-/usr vs. partially-symlink-farmed-root Luca Boccassi <bluca@debian.org> - 2021-08-22 12:30 +0200
Re: merged-/usr vs. partially-symlink-farmed-root Marvin Renich <mrvn@renich.org> - 2021-08-22 18:40 +0200
Re: merged-/usr vs. partially-symlink-farmed-root Simon Richter <sjr@debian.org> - 2021-08-22 19:00 +0200
Re: merged-/usr vs. partially-symlink-farmed-root Luca Boccassi <bluca@debian.org> - 2021-08-22 23:30 +0200
Re: merged-/usr vs. partially-symlink-farmed-root "Theodore Ts'o" <tytso@mit.edu> - 2021-08-23 00:20 +0200
Re: merged-/usr vs. partially-symlink-farmed-root Ansgar <ansgar@43-1.org> - 2021-08-22 23:30 +0200
Re: merged-/usr vs. partially-symlink-farmed-root Marvin Renich <mrvn@renich.org> - 2021-08-23 16:40 +0200
Re: merged-/usr vs. partially-symlink-farmed-root Ansgar <ansgar@43-1.org> - 2021-08-23 17:20 +0200
Re: merged-/usr vs. partially-symlink-farmed-root Marvin Renich <mrvn@renich.org> - 2021-08-23 18:30 +0200
Re: merged /usr vs. symlink farms Tomas Pospisek <tpo2@sourcepole.ch> - 2021-08-22 21:30 +0200
Re: testing for rootfs vs. /usr reproducibility regressions Simon McVittie <smcv@debian.org> - 2021-08-19 12:50 +0200
Re: testing for rootfs vs. /usr reproducibility regressions Helmut Grohne <helmut@subdivi.de> - 2021-08-20 10:20 +0200
Re: testing for rootfs vs. /usr reproducibility regressions Simon McVittie <smcv@debian.org> - 2021-08-20 12:40 +0200
Re: testing for rootfs vs. /usr reproducibility regressions Timothy M Butterworth <timothy.m.butterworth@gmail.com> - 2021-08-20 23:40 +0200
Re: testing for rootfs vs. /usr reproducibility regressions Andy Smith <andy@strugglers.net> - 2021-08-21 19:30 +0200
Re: testing for rootfs vs. /usr reproducibility regressions Timothy M Butterworth <timothy.m.butterworth@gmail.com> - 2021-08-21 22:20 +0200
Re: A summary of where I think we are on the technical side of the merged /usr discussion Luca Boccassi <bluca@debian.org> - 2021-08-18 00:10 +0200
Re: A summary of where I think we are on the technical side of the merged /usr discussion Sam Hartman <hartmans@debian.org> - 2021-08-18 07:00 +0200
Re: A summary of where I think we are on the technical side of the merged /usr discussion Tim Woodall <debiandevel@woodall.me.uk> - 2021-08-18 18:20 +0200
Changing how you do things: Was Re: merged /usr Tim Woodall <debiandevel@woodall.me.uk> - 2021-08-18 09:50 +0200
Re: Changing how you do things: Was Re: merged /usr David Kalnischkies <david@kalnischkies.de> - 2021-08-18 15:00 +0200
Re: merged /usr David Kalnischkies <david@kalnischkies.de> - 2021-08-16 11:50 +0200
Re: merged /usr Holger Levsen <holger@layer-acht.org> - 2021-08-17 11:50 +0200
Re: merged /usr Vagrant Cascadian <vagrant@reproducible-builds.org> - 2021-08-17 18:30 +0200
Re: merged /usr Simon McVittie <smcv@debian.org> - 2021-08-17 19:00 +0200
Re: merged /usr Holger Levsen <holger@layer-acht.org> - 2021-08-17 19:20 +0200
Re: merged /usr Wouter Verhelst <wouter@debian.org> - 2021-08-16 16:10 +0200
Re: merged /usr Wouter Verhelst <wouter@debian.org> - 2021-08-16 16:10 +0200
Re: merged /usr Marco d'Itri <md@Linux.IT> - 2021-08-16 16:20 +0200
Re: merged /usr Wouter Verhelst <wouter@debian.org> - 2021-08-16 17:00 +0200
Re: merged /usr Marc Haber <mh+debian-devel@zugschlus.de> - 2021-08-17 19:10 +0200
Re: merged /usr Sam Hartman <hartmans@debian.org> - 2021-08-16 23:50 +0200
Re: merged /usr Wouter Verhelst <wouter@debian.org> - 2021-07-27 17:10 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Svante Signell <svante.signell@gmail.com> - 2021-07-18 21:00 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-07-18 23:50 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-07-19 00:00 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Andy Smith <andy@strugglers.net> - 2021-07-19 01:50 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-07-19 00:10 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Marco d'Itri <md@Linux.IT> - 2021-07-19 00:20 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-07-19 00:30 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Russ Allbery <rra@debian.org> - 2021-07-19 01:30 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Russ Allbery <rra@debian.org> - 2021-07-19 01:30 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2021-07-19 03:20 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Russ Allbery <rra@debian.org> - 2021-07-19 04:10 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Marc Haber <mh+debian-devel@zugschlus.de> - 2021-07-19 07:30 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Stephan Verbücheln <verbuecheln@posteo.de> - 2021-07-19 07:50 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Marco d'Itri <md@Linux.IT> - 2021-07-19 10:30 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Michael Biebl <biebl@debian.org> - 2021-07-19 15:30 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Marc Haber <mh+debian-devel@zugschlus.de> - 2021-07-19 18:40 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Svante Signell <svante.signell@gmail.com> - 2021-07-19 00:30 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Russ Allbery <rra@debian.org> - 2021-07-19 01:30 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Thomas Goirand <zigo@debian.org> - 2021-07-16 10:10 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Thomas Goirand <zigo@debian.org> - 2021-07-16 13:40 +0200
Re: merged /usr considered harmful Thorsten Glaser <tg@debian.org> - 2021-07-17 23:20 +0200
Re: merged /usr considered harmful Geert Stappers <stappers@stappers.nl> - 2021-07-18 08:40 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Simon McVittie <smcv@debian.org> - 2021-07-18 00:30 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Marco d'Itri <md@Linux.IT> - 2021-07-18 11:20 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Bastian Blank <waldi@debian.org> - 2021-07-18 12:30 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Stephan Verbücheln <verbuecheln@posteo.de> - 2021-07-18 13:20 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Andrey Rahmatullin <wrar@debian.org> - 2021-07-18 13:20 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Marco d'Itri <md@Linux.IT> - 2021-07-18 18:00 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Stephan Verbücheln <verbuecheln@posteo.de> - 2021-07-18 19:00 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Andrey Rahmatullin <wrar@debian.org> - 2021-07-18 19:20 +0200
Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) Andrey Rahmatullin <wrar@debian.org> - 2021-07-18 19:20 +0200
Page 12 of 13 — ← Prev page 1 … 10 11 [12] 13 Next page →
| From | Marco d'Itri <md@Linux.IT> |
|---|---|
| Date | 2021-07-19 00:20 +0200 |
| Message-ID | <CCniF-3x2-1@gated-at.bofh.it> |
| In reply to | #100796 |
[Multipart message — attachments visible in raw view] — view raw
On Jul 19, Polyna-Maude Racicot-Summerside <debian@polynamaude.com> 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
[toc] | [prev] | [next] | [standalone]
| From | Polyna-Maude Racicot-Summerside <debian@polynamaude.com> |
|---|---|
| Date | 2021-07-19 00:30 +0200 |
| Message-ID | <CCnsm-3DF-5@gated-at.bofh.it> |
| In reply to | #100797 |
[Multipart message — attachments visible in raw view] — view raw
Hi, On 2021-07-18 6:17 p.m., Marco d'Itri wrote: > On Jul 19, Polyna-Maude Racicot-Summerside <debian@polynamaude.com> 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% / tmpfs 16G 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/sda8 88G 60M 83G 1% /usr/local /dev/sda7 92G 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
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2021-07-19 01:30 +0200 |
| Message-ID | <CCoop-4e6-3@gated-at.bofh.it> |
| In reply to | #100799 |
Russ Allbery <rra@debian.org> 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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2021-07-19 01:30 +0200 |
| Message-ID | <CCoop-4e6-5@gated-at.bofh.it> |
| In reply to | #100799 |
Polyna-Maude Racicot-Summerside <debian@polynamaude.com> 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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
| From | Polyna-Maude Racicot-Summerside <debian@polynamaude.com> |
|---|---|
| Date | 2021-07-19 03:20 +0200 |
| Message-ID | <CCq6R-5h9-1@gated-at.bofh.it> |
| In reply to | #100801 |
[Multipart message — attachments visible in raw view] — view raw
Hi, On 2021-07-18 7:21 p.m., Russ Allbery wrote: > Polyna-Maude Racicot-Summerside <debian@polynamaude.com> 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
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2021-07-19 04:10 +0200 |
| Message-ID | <CCqTg-5LR-1@gated-at.bofh.it> |
| In reply to | #100804 |
Polyna-Maude Racicot-Summerside <debian@polynamaude.com> 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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+debian-devel@zugschlus.de> |
|---|---|
| Date | 2021-07-19 07:30 +0200 |
| Subject | Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) |
| Message-ID | <CCu0N-7J5-1@gated-at.bofh.it> |
| In reply to | #100801 |
On Sun, 18 Jul 2021 16:21:24 -0700, Russ Allbery <rra@debian.org> 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
[toc] | [prev] | [next] | [standalone]
| From | Stephan Verbücheln <verbuecheln@posteo.de> |
|---|---|
| Date | 2021-07-19 07:50 +0200 |
| Message-ID | <CCuk9-7Ph-3@gated-at.bofh.it> |
| In reply to | #100809 |
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
[toc] | [prev] | [next] | [standalone]
| From | Marco d'Itri <md@Linux.IT> |
|---|---|
| Date | 2021-07-19 10:30 +0200 |
| Message-ID | <CCwP0-13q-3@gated-at.bofh.it> |
| In reply to | #100809 |
[Multipart message — attachments visible in raw view] — view raw
On Jul 19, Marc Haber <mh+debian-devel@zugschlus.de> 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
[toc] | [prev] | [next] | [standalone]
| From | Michael Biebl <biebl@debian.org> |
|---|---|
| Date | 2021-07-19 15:30 +0200 |
| Message-ID | <CCBlD-3R5-1@gated-at.bofh.it> |
| In reply to | #100809 |
[Multipart message — attachments visible in raw view] — view raw
Am 19.07.21 um 07:23 schrieb Marc Haber: > 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. I think this is a misunderstanding. Files from / would be moved to /usr. So the only way this could fail is, if your /usr partition was too small.That's still a possibility for existing systems, but a much smaller one then moving files from /usr to /. Typically a separate /usr partition is larger then /. >> 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. I assume you are referring to the sulogin issue here [1], i.e. whether we require a root password on an emergency failure or not. Fwiw, this is mostly me being paranoid and not handing out root shells. This has nothing to do with merged-/usr. Michael [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+debian-devel@zugschlus.de> |
|---|---|
| Date | 2021-07-19 18:40 +0200 |
| Subject | Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) |
| Message-ID | <CCEtb-5G6-1@gated-at.bofh.it> |
| In reply to | #100816 |
On Mon, 19 Jul 2021 15:19:32 +0200, Michael Biebl <biebl@debian.org> wrote: >Am 19.07.21 um 07:23 schrieb Marc Haber: >> 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. > >I think this is a misunderstanding. Files from / would be moved to /usr. >So the only way this could fail is, if your /usr partition was too >small.That's still a possibility for existing systems, but a much >smaller one then moving files from /usr to /. Typically a separate /usr >partition is larger then /. Right, that sounds much easier. It's still an Open Heart Operation, especially for systems that I don't have out of band access for, which is rather common for smaller installations. >I assume you are referring to the sulogin issue here [1], i.e. whether >we require a root password on an emergency failure or not. Yes. From my point of view, this is taking away a freedom from the local admin. In an ideal world, boot failure behavior would be locally configurable. A mis-booted sysv system, if I remember correctly (I have been a mostly happy systemd user for already quite some time), could be told to "just try to continue and show me how far you get", which in the vast majority of cases led to a regular login prompt from which the user-login-plus-sudo routine just worked. This didn't hand out any more root shells than the current way of stopping dead and refusing to do anything without the "real" root password, as far as I understand. I probably don't have enough experience to have the final call on that. But it's just a pet peeve of mine that I can easily live with. >Fwiw, this is mostly me being paranoid and not handing out root shells. It's good to be paranoid by default. It's bad to force that paranoia on the local admin who might have a choice to move to a different distribution. But alas, the others do it the same way. So it's just freedom lost. >This has nothing to do with merged-/usr. I never said it has. 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
[toc] | [prev] | [next] | [standalone]
| From | Svante Signell <svante.signell@gmail.com> |
|---|---|
| Date | 2021-07-19 00:30 +0200 |
| Message-ID | <CCnsl-3DF-1@gated-at.bofh.it> |
| In reply to | #100790 |
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 +0000, 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?
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2021-07-19 01:30 +0200 |
| Message-ID | <CCoop-4e6-1@gated-at.bofh.it> |
| In reply to | #100798 |
Svante Signell <svante.signell@gmail.com> 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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
| From | Thomas Goirand <zigo@debian.org> |
|---|---|
| Date | 2021-07-16 10:10 +0200 |
| Message-ID | <CBr4Z-kk-1@gated-at.bofh.it> |
| In reply to | #100738 |
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)
[toc] | [prev] | [next] | [standalone]
| From | Thomas Goirand <zigo@debian.org> |
|---|---|
| Date | 2021-07-16 13:40 +0200 |
| Message-ID | <CBumd-2kb-3@gated-at.bofh.it> |
| In reply to | #100758 |
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)
[toc] | [prev] | [next] | [standalone]
| From | Thorsten Glaser <tg@debian.org> |
|---|---|
| Date | 2021-07-17 23:20 +0200 |
| Subject | Re: merged /usr considered harmful |
| Message-ID | <CBZT4-5tn-3@gated-at.bofh.it> |
| In reply to | #100758 |
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)
[toc] | [prev] | [next] | [standalone]
| From | Geert Stappers <stappers@stappers.nl> |
|---|---|
| Date | 2021-07-18 08:40 +0200 |
| Subject | Re: merged /usr considered harmful |
| Message-ID | <CC8CZ-2Ma-1@gated-at.bofh.it> |
| In reply to | #100776 |
Summary: let go, let go On Sat, Jul 17, 2021 at 09:13:57PM +0000, 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
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2021-07-18 00:30 +0200 |
| Message-ID | <CC0YN-64n-3@gated-at.bofh.it> |
| In reply to | #100758 |
On Sat, 17 Jul 2021 at 20:34:41 +0000, 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
deduplication on the storage backend (for example, if /usr is NFS-shared
and is stored on btrfs on the NFS server, then reflinks could be used to
make files with identical content share storage).
If the FHS allows something, that also does not mean "all FHS-compliant
operating systems must allow this"; it just means "programs designed to
run on FHS-compliant operating systems must not assume this can't happen".
For example, the FHS allows /run and /var/run to be separate, but on
Debian they are always synonymous (because making them distinct would
only cause problems, without providing any benefit). If Debian did not
support a network-mounted /usr, then asking for network-mounted /usr to be
supported would be a reasonable feature request, but the lack of that
feature would not make Debian any less FHS-compliant.
smcv
[toc] | [prev] | [next] | [standalone]
| From | Marco d'Itri <md@Linux.IT> |
|---|---|
| Date | 2021-07-18 11:20 +0200 |
| Message-ID | <CCb7Q-4vG-1@gated-at.bofh.it> |
| In reply to | #100777 |
[Multipart message — attachments visible in raw view] — view raw
On Jul 18, Simon McVittie <smcv@debian.org> 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
[toc] | [prev] | [next] | [standalone]
| From | Bastian Blank <waldi@debian.org> |
|---|---|
| Date | 2021-07-18 12:30 +0200 |
| Message-ID | <CCcdA-5aZ-3@gated-at.bofh.it> |
| In reply to | #100782 |
On Sun, Jul 18, 2021 at 11:13:37AM +0200, Marco d'Itri wrote: > On Jul 18, Simon McVittie <smcv@debian.org> 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
[toc] | [prev] | [next] | [standalone]
Page 12 of 13 — ← Prev page 1 … 10 11 [12] 13 Next page →
Back to top | Article view | linux.debian.devel
csiph-web