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 5 of 13 — ← Prev page 1 … 3 4 [5] 6 7 … 13 Next page →
| From | Sam Hartman <hartmans@debian.org> |
|---|---|
| Date | 2021-08-17 16:10 +0200 |
| Subject | A summary of where I think we are on the technical side of the merged /usr discussion |
| Message-ID | <CN7WV-68W-9@gated-at.bofh.it> |
| In reply to | #101083 |
[Multipart message — attachments visible in raw view] — view raw
>>>>> "Luca" == Luca Boccassi <bluca@debian.org> writes:
Luca> On Tue, 2021-08-17 at 12:07 +0200, David Kalnischkies wrote:
Luca> If src:usrmerge is made transitively-essential, from that
Luca> point onward it wouldn't matter if a package is no longer
Luca> compatible with the legacy split-usr setup, no?
No, there are upgrades to consider.
We know at the end of the upgrade all the essential packages are going
to be installed.
But especially within the pseudo essential set we do not typically have
ordering guarantees.
So, we generally assume that we need to wait until the release after
such a transition is introduced to depend on it.
So, we can depend on usrmerge for bookworm+1 but not for bookworm.
That is at least Simon's position.
Several people have argued that's not actually what the TC said, but
it's certainly how we normally operate, and at least one prominent
member of the TC appears to be saying that is what the TC meant.
So the current assumption in the discussion is that packages inthe
bookworm development cycle must work both with and without usrmerge.
If you propose a transition faster than that, you have a lot of
difficult questions to answer about corner cases involvind partial
upgrades and what happens during upgrades.
In order to build packages that work on a non-usrmerge system, you need
a build chroot that is not usrmerge.
There are a couple of consequences of that:
1) We need to support non-usrmerge build chroots through the bookworm
cycle.
2) If you are going to automatically upgrade systems for example by
having usrmerge become essential, you need a way to exempt at least
build chroots.
--Sam
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2021-08-17 18:20 +0200 |
| Subject | Re: A summary of where I think we are on the technical side of the merged /usr discussion |
| Message-ID | <CN9YJ-7pl-3@gated-at.bofh.it> |
| In reply to | #101088 |
On Tue, 17 Aug 2021 at 08:08:15 -0600, Sam Hartman wrote:
> In order to build packages that work on a non-usrmerge system, you need
> a build chroot that is not usrmerge.
Well. That's not 100% true: it's more accurate to say that when *some*
source packages are built in a merged-/usr chroot, the resulting binary
packages don't work correctly on a non-merged-/usr system. Most source
packages are fine either way.
Such packages are already violating a Policy "should", because they're
not building reproducibly (and the reproducible-builds infra tests this
for testing and unstable). Ansgar did a survey of this when we were
discussing one of the Technical Committee bugs, and reported that around
80 packages had a bug of this class at the time, which had apparently
dropped to 29 by the time the TC resolution was voted on.
If we want to make buildd chroots merged-/usr any time soon, then I
think we need to say this class of bugs is RC for bookworm.
Re-reading TC resolution #914897, it's possible that these bugs are
*already* RC - at least, that's one possible interpretation of what we
resolved.
However, if we keep the buildd chroots unmerged-/usr in order to avoid
these bugs becoming significant, then, yes, we get the consequences
you described.
This class of bugs applies equally to anything that makes an executable
available at both /bin/foo and /usr/bin/foo, so even if people want to
disregard the two Technical Committee resolutions on the subject of
merged-/usr and look for consensus around symlink farms in the root
filesystem instead, we'll probably still need to make sure bugs of this
class get fixed.
smcv
[toc] | [prev] | [next] | [standalone]
| From | "Theodore Ts'o" <tytso@mit.edu> |
|---|---|
| Date | 2021-08-17 19:00 +0200 |
| Subject | Re: A summary of where I think we are on the technical side of the merged /usr discussion |
| Message-ID | <CNaBr-7D0-1@gated-at.bofh.it> |
| In reply to | #101090 |
On Tue, Aug 17, 2021 at 05:19:06PM +0100, Simon McVittie wrote:
> On Tue, 17 Aug 2021 at 08:08:15 -0600, Sam Hartman wrote:
> > In order to build packages that work on a non-usrmerge system, you need
> > a build chroot that is not usrmerge.
>
> Well. That's not 100% true: it's more accurate to say that when *some*
> source packages are built in a merged-/usr chroot, the resulting binary
> packages don't work correctly on a non-merged-/usr system. Most source
> packages are fine either way.
>
> Such packages are already violating a Policy "should", because they're
> not building reproducibly (and the reproducible-builds infra tests this
> for testing and unstable). Ansgar did a survey of this when we were
> discussing one of the Technical Committee bugs, and reported that around
> 80 packages had a bug of this class at the time, which had apparently
> dropped to 29 by the time the TC resolution was voted on.
Do we have a dashboard for this so the list of which source packages
result in different binary packages depending on whether they are
built with a usrmerge vs !usrmerge system? We could look at the
reproducible-builds reports, but not all reproducible build failures
are caused by the usrmerge/!usrmerge dependency, right?
> If we want to make buildd chroots merged-/usr any time soon, then I
> think we need to say this class of bugs is RC for bookworm.
Agreed; I'd go further, and claim we should get all of these bugs
resolved well before the bookworm freeze.
On a separate question, at the moment e2fsprogs is installing some
files in /sbin and /lib, and other in /usr/sbin and /usr/lib, etc.,
since historically the goal was to allow systems to boot, and bring up
networking, etc., without /usr being mounted. As a result there are
some breakout lintain warnings:
W: libext2fs-dev: breakout-link usr/lib/x86_64-linux-gnu/libe2p.so -> lib/x86_64-linux-gnu/libe2p.so.2
W: libext2fs-dev: breakout-link usr/lib/x86_64-linux-gnu/libext2fs.so -> lib/x86_64-linux-gnu/libext2fs.so.2
W: ss-dev: breakout-link usr/lib/x86_64-linux-gnu/libss.so -> lib/x86_64-linux-gnu/libss.so.2
Suppose I released a new version of e2fsprogs targetting sid and
bookworm which installs everything in /usr/bin, /usr/sbin, /usr/lib,
etc, instead of splitting up files in /... and /usr/...
* Is this a desirable thing to do now? (Post-bullseye release)
* What are the potential risks of doing this now?
* Bullseye users might still be assuming that they can boot w/o
/usr mounted, is that correct? Hence, for bullseye-backports, I
would need to be able to support building e2fsprogs packages
which retain some files being installed in /{bin,sbin,lib},
etc., and some in /usr/{bin,sbin,lib},
Apologies for asking these potentially stupid questions, but it would
be great if there could be concrete guidelines could be given for
package maintainers, not just what is *mandatory* (which would be in
policy), and what would be considered *desirable* for a package
maintainer who wants to be helpful/proactive and is trying to move the
ball forward.
- Ted
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2021-08-17 20:10 +0200 |
| Subject | Re: A summary of where I think we are on the technical side of the merged /usr discussion |
| Message-ID | <CNbHb-ky-3@gated-at.bofh.it> |
| In reply to | #101092 |
On Tue, 17 Aug 2021 at 12:59:21 -0400, Theodore Ts'o wrote:
> > Such packages are already violating a Policy "should", because they're
> > not building reproducibly (and the reproducible-builds infra tests this
> > for testing and unstable).
>
> Do we have a dashboard for this so the list of which source packages
> result in different binary packages depending on whether they are
> built with a usrmerge vs !usrmerge system? We could look at the
> reproducible-builds reports, but not all reproducible build failures
> are caused by the usrmerge/!usrmerge dependency, right?
Sort of. For packages where someone from the reproducible-builds team
has done the analysis,
https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html
and similar pages for other suites.
Additionally,
https://tests.reproducible-builds.org/debian/unstable/amd64/index_no_notes.html
and similar pages list packages that have not been analyzed or categorized,
and *might* have this issue.
> On a separate question, at the moment e2fsprogs is installing some
> files in /sbin and /lib, and other in /usr/sbin and /usr/lib, etc.,
> since historically the goal was to allow systems to boot, and bring up
> networking, etc., without /usr being mounted.
Right. Booting without /usr is unsupported since buster, but if your
package was traditionally split between the rootfs and /usr, the
conservative thing to do is to leave it as-is.
> As a result there are some breakout lintain warnings:
>
> W: libext2fs-dev: breakout-link usr/lib/x86_64-linux-gnu/libe2p.so -> lib/x86_64-linux-gnu/libe2p.so.2
> W: libext2fs-dev: breakout-link usr/lib/x86_64-linux-gnu/libext2fs.so -> lib/x86_64-linux-gnu/libext2fs.so.2
> W: ss-dev: breakout-link usr/lib/x86_64-linux-gnu/libss.so -> lib/x86_64-linux-gnu/libss.so.2
I don't know what the purpose of the breakout-link tag is, to be honest.
It seems like it's often a false-positive, and I don't think these links
are bugs.
> Suppose I released a new version of e2fsprogs targetting sid and
> bookworm which installs everything in /usr/bin, /usr/sbin, /usr/lib,
> etc, instead of splitting up files in /... and /usr/...
>
> * Is this a desirable thing to do now? (Post-bullseye release)
Maybe.
If a distro-wide migration to merged-/usr is genuinely happening (and the
project isn't going to hold a GR to overrule the Technical Committee or
anything like that), then one point of view says the pragmatic thing to
do might be to leave this package as-is until the bookworm+1 cycle opens,
and then simplify it by taking advantage of merged-/usr being the only
supported filesystem layout; moving the files around is a potential
source of bugs, and the transition to merged-/usr will resolve it for
you with less work.
However, some people (most notably the dpkg maintainer, who has thought
about this more than most) argue that merged-/usr's "aliasing" symlinks
/bin -> usr/bin, etc. are unsupportable, and the only correct way to
consolidate static files to be physically located under /usr is to
gradually build up symlink farms below /bin and so on. If people with this
point of view turn out to represent project consensus, or if they do not
represent consensus but are sufficiently loud that they delay merged-/usr
indefinitely, then waiting for merged-/usr to solve the problem for you
might not be viable.
If your opinion is somewhere in between those extremes, then you might be
willing to do the work of migrating files from the root filesystem into
/usr in order to hedge your bets, even though you expect a more general
distro-wide move to merged-/usr to make the distinction irrelevant in
practice. This is what has happened in dbus and glib2.0.
> * What are the potential risks of doing this now?
For users of non-merged-/usr
----------------------------
If components of your package implement a third-party filesystem "API",
then you need to check that the consumer is going to look in both the
rootfs and /usr. For e2fsprogs, I would expect the problem areas to be
the /sbin/fsck.TYPE and /sbin/mkfs.TYPE interfaces: if you install
to /usr/sbin/fsck.TYPE and /usr/sbin/mkfs.TYPE, will the fsck and mkfs
wrappers in util-linux still find them?
If paths from your package are hard-coded somewhere, and are no longer
the physical location of the file, then you will need a compat symlink.
Because merged-/usr exists, you cannot ship both /foo and /usr/foo in
the data.tar.*; you will have to create the compat symlink from the
maintainer scripts. The handling of /{usr/,}bin/touch in coreutils is a
nice simple example. This is most likely to affect executables, because
the paths to shared libraries are not usually hard-coded.
If your shared libraries somehow hit the same mysterious bug discussed
in #911225 and #949395, with the old libraries not getting removed
from their path on the root filesystem, then you might have to apply
the same workaround we did in GLib (GLib has a generic script you can
copy for this, at your own risk). This failure mode has been seen in GLib
(multiple times) and libcrypt (once). I still have no idea how it happens,
or why it affected GLib more than other packages...
For users of merged-/usr
------------------------
If you get the maintainer-script glue for compat symlinks wrong, then
the package might become uninstallable or otherwise broken on merged-/usr
systems. autopkgtest and piuparts can help to detect this.
If merged-/usr does indeed become mandatory for bookworm as the Technical
Committe have recommended, then you might feel that the work you've done
on disentangling this was a waste of effort, and you might wish you had
left the package as-is until the beginning of the bookworm+1 cycle and
then drastically simplified it by taking advantage of merged-/usr being
the only supported layout.
Generally
---------
For completeness:
If the project as a whole reaches consensus that the Technical Committee
have been consistently wrong about merged-/usr since late 2018, and
overrules us via a GR, then you might have to change how this works.
Or, if someone finds a showstopper issue with merged-/usr that has not
been a serious practical problem in buster, bullseye, Ubuntu, Fedora or
Arch but turns out to be sufficiently bad to make the TC change our minds,
then similarly you might have to change how this works.
> * Bullseye users might still be assuming that they can boot w/o
> /usr mounted, is that correct?
No, this has been officially unsupported since buster. (Perhaps users
still have this assumption, but if they do, they're wrong.)
smcv
[toc] | [prev] | [next] | [standalone]
| From | Simon Richter <sjr@debian.org> |
|---|---|
| Date | 2021-08-17 21:20 +0200 |
| Subject | Re: A summary of where I think we are on the technical side of the merged /usr discussion |
| Message-ID | <CNcMW-12q-15@gated-at.bofh.it> |
| In reply to | #101099 |
[Multipart message — attachments visible in raw view] — view raw
Hi,
On 8/17/21 8:02 PM, Simon McVittie wrote:
> However, some people (most notably the dpkg maintainer, who has thought
> about this more than most) argue that merged-/usr's "aliasing" symlinks
> /bin -> usr/bin, etc. are unsupportable, and the only correct way to
> consolidate static files to be physically located under /usr is to
> gradually build up symlink farms below /bin and so on.
I agree that it's likely the only thing we can do with the version of
dpkg that we ship now, and that will have to handle the upgrade for any
users that move from one stable release to the next provided there is no
project consensus to deviate from "apt dist-upgrade" as the preferred
method of upgrading to the next release.
The two main constraints are:
1. At any point that the resolver in stable apt or stable aptitude
invokes a new dpkg call, the PATH needs to contain "sh", "rm", "tar",
"diff", "dpkg-deb", "ldconfig" and "start-stop-daemon", and the first
entry it finds will be examined with stat() for ugo+x, or dpkg will
declare the system to be broken and refuse to operate.
2. In any order of operations generated by the apt and aptitude
resolvers from any starting configuration consisting of packages from
stable, backports, testing and unstable (but not older), maintainer
scripts need to work.
That is an awfully big search space that we'd have to cover if we still
want upgrades to work smoothly for all users, including those who are
installing backports or pull single packages from testing or unstable.
We can add features to dpkg to facilitate an instantaneous switch from
the symlink farm to a full usrmerge system, but this could also be
encoded in a preinst.
The algorithm would be
1. if the target in the toplevel directory is already a symlink, we're done
2. if the target in the toplevel is a directory, verify that it only
contains other directories and symlinks. Optionally, verify that the
same names exist below the target of the link we're trying to create
3. rename old dir
4. create symlink
5. remove old dir
This would work either as a change to unpack.c:1373 and following, or as
a preinst of a package shipping the symlinks in the data archive. Both
places would be effectively atomic from the view of all affected
components, and both would require the new package to conflict with any
current package that ships a file below a path that needs to be moved.
What is unclear is how that new package would be pulled in, both during
installation and during upgrade, as it would have to be unpacked rather
late, and we'd probably have to verify that none of the resolvers tries
to --force things in an unexpected way.
The other question is whether we want a more robust, possibly
declarative, system to determine the contents of the initramfs, as that
effectively takes over the function of the root filesystem.
Simon
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2021-08-18 00:30 +0200 |
| Subject | Re: A summary of where I think we are on the technical side of the merged /usr discussion |
| Message-ID | <CNfKO-2SB-5@gated-at.bofh.it> |
| In reply to | #101101 |
On Tue, 17 Aug 2021 at 20:17, Simon Richter <sjr@debian.org> wrote: > > Hi, > > On 8/17/21 8:02 PM, Simon McVittie wrote: > > > However, some people (most notably the dpkg maintainer, who has thought > > about this more than most) argue that merged-/usr's "aliasing" symlinks > > /bin -> usr/bin, etc. are unsupportable, and the only correct way to > > consolidate static files to be physically located under /usr is to > > gradually build up symlink farms below /bin and so on. > > I agree that it's likely the only thing we can do with the version of > dpkg that we ship now, and that will have to handle the upgrade for any > users that move from one stable release to the next provided there is no > project consensus to deviate from "apt dist-upgrade" as the preferred > method of upgrading to the next release. That is the case only if the plan is to deprecate support for external/third-party repositories/packages, since there's no way to do the required per-package work on those, and this strategy can only work (and that's a non-trivial assumption already, given so far it has a 100% failure rate) if every single package that will ever be installed on every single system is updated individually. Also the "unsupportable" statement is kinda hard to reconcile with the reality of this being default on Ubuntu for 2+ years, which uses the very same dpkg. It would be very useful to have someone from Canonical comment on what problems are there in reality? Launchpad shows only 2 bugs, which appears to be both corner cases: https://bugs.launchpad.net/ubuntu/+source/usrmerge
[toc] | [prev] | [next] | [standalone]
| From | Simon Richter <sjr@debian.org> |
|---|---|
| Date | 2021-08-18 10:50 +0200 |
| Subject | Re: A summary of where I think we are on the technical side of the merged /usr discussion |
| Message-ID | <CNpqO-1f5-15@gated-at.bofh.it> |
| In reply to | #101107 |
[Multipart message — attachments visible in raw view] — view raw
Hi,
On 8/18/21 12:21 AM, Luca Boccassi wrote:
> On Tue, 17 Aug 2021 at 20:17, Simon Richter <sjr@debian.org> wrote:
>> I agree that it's likely the only thing we can do with the version of
>> dpkg that we ship now, and that will have to handle the upgrade for any
>> users that move from one stable release to the next provided there is no
>> project consensus to deviate from "apt dist-upgrade" as the preferred
>> method of upgrading to the next release.
> That is the case only if the plan is to deprecate support for
> external/third-party repositories/packages, since there's no way to do
> the required per-package work on those, and this strategy can only
> work (and that's a non-trivial assumption already, given so far it has
> a 100% failure rate) if every single package that will ever be
> installed on every single system is updated individually.
My expectation would be that there are rather few third-party packages
installing files into the directories we want to clear out, and we have
two years in which we can tell people to get these packages updated.
> Also the "unsupportable" statement is kinda hard to reconcile with the
> reality of this being default on Ubuntu for 2+ years, which uses the
> very same dpkg. It would be very useful to have someone from Canonical
> comment on what problems are there in reality? Launchpad shows only 2
> bugs, which appears to be both corner cases:
> https://bugs.launchpad.net/ubuntu/+source/usrmerge
That is why I wrote "provided there is no project consensus to deviate
from "apt dist-upgrade" as the preferred method of upgrading to the next
release." This is what Ubuntu did.
We can repeat that, which will anger a lot of users.
Simon
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2021-08-18 11:50 +0200 |
| Subject | Re: A summary of where I think we are on the technical side of the merged /usr discussion |
| Message-ID | <CNqmR-1N8-1@gated-at.bofh.it> |
| In reply to | #101119 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, 2021-08-18 at 10:43 +0200, Simon Richter wrote: > Hi, > > On 8/18/21 12:21 AM, Luca Boccassi wrote: > > > On Tue, 17 Aug 2021 at 20:17, Simon Richter <sjr@debian.org> wrote: > > > > I agree that it's likely the only thing we can do with the version of > > > dpkg that we ship now, and that will have to handle the upgrade for any > > > users that move from one stable release to the next provided there is no > > > project consensus to deviate from "apt dist-upgrade" as the preferred > > > method of upgrading to the next release. > > > That is the case only if the plan is to deprecate support for > > external/third-party repositories/packages, since there's no way to do > > the required per-package work on those, and this strategy can only > > work (and that's a non-trivial assumption already, given so far it has > > a 100% failure rate) if every single package that will ever be > > installed on every single system is updated individually. > > My expectation would be that there are rather few third-party packages > installing files into the directories we want to clear out, and we have > two years in which we can tell people to get these packages updated. Given we are talking about /bin /lib and so on, there are many, many that actually do. Most don't even use dpkg-buildpackage to build, let alone debhelper, but third party systems like cmake/gradle, most often than not vendored and pinned at a specific version. Or even worse custom makefiles/scripts, which might not even be developed publicly. The usrmerge approach deals with this just fine. What is the concrete plan of action for the symlink-farm approach to 1) find them all out, and 2) to update them all? There has to be one: otherwise there will be an unspecified and unknowable large number of machines that forever will be unable to run the proposed algorithm to switch from symlink farm to actual usr-merged, with no path to move out of it, so the two states will always have to be supported: symlinks farm and real merged- usr. > > Also the "unsupportable" statement is kinda hard to reconcile with the > > reality of this being default on Ubuntu for 2+ years, which uses the > > very same dpkg. It would be very useful to have someone from Canonical > > comment on what problems are there in reality? Launchpad shows only 2 > > bugs, which appears to be both corner cases: > > https://bugs.launchpad.net/ubuntu/+source/usrmerge > > That is why I wrote "provided there is no project consensus to deviate > from "apt dist-upgrade" as the preferred method of upgrading to the next > release." This is what Ubuntu did. > > We can repeat that, which will anger a lot of users. What specific features/workaround/fixes/etc were implemented in the Ubuntu upgrader to deal with merged-usr? -- Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | "Theodore Ts'o" <tytso@mit.edu> |
|---|---|
| Date | 2021-08-18 05:30 +0200 |
| Subject | Re: A summary of where I think we are on the technical side of the merged /usr discussion |
| Message-ID | <CNkr7-662-3@gated-at.bofh.it> |
| In reply to | #101099 |
Simon, Thanks so much for your comprehensive answer. It's a great summary that I think would be really useful for those of us who are package maintainers who don't have a strong position one way or another vis-a-vis usrmerge vs merged-/usr-via-symlink-farms, but just want to do what is best for our users. I guess I was thinking that if individual packages could just move all of the files to /usr/..., then how the symlinks would be handled might not matter as much. > If components of your package implement a third-party filesystem "API", > then you need to check that the consumer is going to look in both the > rootfs and /usr. For e2fsprogs, I would expect the problem areas to be > the /sbin/fsck.TYPE and /sbin/mkfs.TYPE interfaces: if you install > to /usr/sbin/fsck.TYPE and /usr/sbin/mkfs.TYPE, will the fsck and mkfs > wrappers in util-linux still find them? So long as PATH includes /sbin and /usr/sbin, the fsck and mkfs wrappers will find them. For fsck there is a failsafe in case PATH is not set, and so it might be a good idea (although probably not strictly necessary in Debian systems) to make the following change in util-linux's disk-utils/fsck.c: -#define FSCK_DEFAULT_PATH "/sbin" +#define FSCK_DEFAULT_PATH "/sbin:/usr/sbin" That being said, you do have a good point that there might be scripts that have "/sbin/fsck.<TYPE>" hard-coded in the shell scripts, just as I've seen /bin/rm, /bin/mv, etc., hard coded in some shell scripts --- not to mention "#!/bin/sh" or "#!/bin/bash" as the first line in gazillions of scripts. So getting rid of all of compatibility symlinks whether done via a symlink tree or top-level symlinks for /bin, /sbin, /lib, etc., is probably not realistic for decades. That being said, the number of inodes that we might need for symlink farms for /bin, /sbin, et.al. is *not* something I'm terribly fond of. It's probably not a show-stopper to add that many symlinks, but... yelch. So my personal preference, even if it required making changes in dpkg so it was aware of directory aliases, and requiring that dpkg getting updated first in the bullseye->bookworm upgrade would be to stick with usrmerge. On that front: is the list of potential problems vis-a-vis dpkg and usrmerge here[1] comprehensive? [1] https://wiki.debian.org/Teams/Dpkg/MergedUsr If so, would it perhaps be helpful to consider what might be solutions to the issues listed in [1]? Some of them might not be that hard to mitigate if minor(?) changes to dpkg were contemplated, and some of them might not be hard to mitigate via brute force techniques (e.g., adding /bin/*sh and /usr/bin/*sh to /etc/shells, etc.) - Ted
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2021-08-18 11:20 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CNpTP-1DS-3@gated-at.bofh.it> |
| In reply to | #101112 |
On Tue, 17 Aug 2021 at 23:24:26 -0400, Theodore Ts'o wrote:
> That being said, you do have a good point that there might be scripts
> that have "/sbin/fsck.<TYPE>" hard-coded in the shell scripts, just as
> I've seen /bin/rm, /bin/mv, etc., hard coded in some shell scripts ---
> not to mention "#!/bin/sh" or "#!/bin/bash" as the first line in
> gazillions of scripts. So getting rid of all of compatibility
> symlinks whether done via a symlink tree or top-level symlinks for
> /bin, /sbin, /lib, etc., is probably not realistic for decades.
Yes. This is a large part of why merged-/usr goes for the
maximum-compatibility approach: make literally everything in /bin
(etc.) available via both /bin and /usr/bin (etc.), so that if someone
has hard-coded one of those paths into a script or similar, it doesn't
matter which one they chose (which in the case of upstream software might
have been correct for their distro but not for historical Debian). Doing
this for everything is simpler and more consistent than trying to decide
whether it's necessary case-by-case.
I'm not sure whether there's any plan to remove the /bin, /sbin, /lib
symlinks *ever* - things like /bin/sh are a de facto API, and the
ELF interpreters like /lib/ld-linux.so.2 are part of their respective
architectures' interoperable ABIs (to the extent that we make exceptions
to our usual reluctance to use libQUAL directories, in order to accommodate
/lib64/ld-linux-x86-64.so.2 and similar).
I suspect that hard-coding paths to "sbin executables" might be more
common than "bin executables", because /sbin:/usr/sbin are not in the
default PATH for non-root users on distros like Debian (that's the point
of sbin after all), but it's sometimes useful for non-root users to invoke
a sbin executable even though they are not root - for example to run mkfs
on a disk image in a file, or to query the contents of the ldconfig cache.
> That being said, the number of inodes that we might need for symlink
> farms for /bin, /sbin, et.al. is *not* something I'm terribly fond of.
> It's probably not a show-stopper to add that many symlinks,
> but... yelch. So my personal preference, even if it required making
> changes in dpkg so it was aware of directory aliases, and requiring
> that dpkg getting updated first in the bullseye->bookworm upgrade
> would be to stick with usrmerge.
Yes. The Technical Committee unanimously voted for merged-/usr (with
the directory aliasing, as implemented in usrmerge and debootstrap)
in #914897, and did not modify this view in #978636, so I'm glad you
agree. Our concern was more about the number of "moving parts" involved
in setting up the symlink farms than about the inode count and aesthetic
properties of a symlink farm, but I can't say the symlink farm is very
appealing aesthetically either!
> On that front: is the list of potential problems vis-a-vis dpkg and
> usrmerge here[1] comprehensive?
>
> [1] https://wiki.debian.org/Teams/Dpkg/MergedUsr
I believe so.
> some of
> them might not be hard to mitigate via brute force techniques (e.g.,
> adding /bin/*sh and /usr/bin/*sh to /etc/shells, etc.)
In many cases that's what's already happening.
smcv
[toc] | [prev] | [next] | [standalone]
| From | Marco d'Itri <md@Linux.IT> |
|---|---|
| Date | 2021-08-18 18:40 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CNwLE-5Id-23@gated-at.bofh.it> |
| In reply to | #101122 |
[Multipart message — attachments visible in raw view] — view raw
On Aug 18, Simon McVittie <smcv@debian.org> wrote: > I'm not sure whether there's any plan to remove the /bin, /sbin, /lib > symlinks *ever* - things like /bin/sh are a de facto API, and the > ELF interpreters like /lib/ld-linux.so.2 are part of their respective > architectures' interoperable ABIs (to the extent that we make exceptions > to our usual reluctance to use libQUAL directories, in order to accommodate > /lib64/ld-linux-x86-64.so.2 and similar). Indeed: there has never been any plan to remove the compatibility symlinks and I still see no point in trying. -- ciao, Marco
[toc] | [prev] | [next] | [standalone]
| From | Helmut Grohne <helmut@subdivi.de> |
|---|---|
| Date | 2021-08-19 10:20 +0200 |
| Subject | Re: A summary of where I think we are on the technical side of the merged /usr discussion |
| Message-ID | <CNLrk-6YG-27@gated-at.bofh.it> |
| In reply to | #101090 |
Hi Simon, On Tue, Aug 17, 2021 at 05:19:06PM +0100, Simon McVittie wrote: > If we want to make buildd chroots merged-/usr any time soon, then I > think we need to say this class of bugs is RC for bookworm. I fear there might be a logic trap here. For a moment, let us assume perfection of this plan: Reproducible builds identify all of the cases that need to be fixed. We bump them to RC bugs. We fix them all. Then we change unstable to be merged-/usr and we're done. Are we? We still need to support partial upgrades from bullseye to bookworm, so - as you pointed out earlier - all packages in bookworm will have to keep this support property. However, our defaulting to merged-/usr makes it impossible for reproducible builds to test it as producing an unmerged chroot is no longer possible. Effectively, the unmerged case will be untested and as a consequence will be broken. For this plan to work, we will have to support unmerged chroots until the end of bookworm, which appears to contradict the premise we started with. > This class of bugs applies equally to anything that makes an executable > available at both /bin/foo and /usr/bin/foo, so even if people want to > disregard the two Technical Committee resolutions on the subject of > merged-/usr and look for consensus around symlink farms in the root > filesystem instead, we'll probably still need to make sure bugs of this > class get fixed. You keep proposing adding /bin/foo -> /usr/bin/foo symbolic links via maintainer scripts. Indeed people are already adding such links. Unfortunately, the way they do it breaks DPKG_ROOT. It also undermines the work of Niels Thykier, myself and others to reduce the number of maintainer scripts in Debian. The collateral damage of the merged-/usr work to the work I'm interested in is huge. Would it be possible to add some central helper for the creation of these links such that I could fix this helper once instead of hunting down hundreds of copies of these DPKG_ROOT bugs with ever more being added? Or maybe we could even do this declaratively by adding a /usr/share/usr-merge.d/<package> file containing paths that need compat symlinks that would be instated by some essential package via triggers? We keep saying that Debian work is voluntary, but this is only true in theory, because Debian is about integrating and combining components. I would like to ignore merged-/usr, but the collateral damage has cost me at least a week already (mostly due to having broken dpkg-shlibdeps). The story is worse for Guillem Jover. We can assert that the current /usr-merge implementation is significantly hampering innovation by dumping work on people that would otherwise improve Debian. It is this aspect that makes me unhappy about merged-/usr. The support received from merged-/usr proponents with diagnosing and fixing issues is suboptimal. Yours disappointed Helmut
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2021-08-19 12:20 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CNNjs-89y-17@gated-at.bofh.it> |
| In reply to | #101165 |
On Thu, 19 Aug 2021 at 10:06:27 +0200, Helmut Grohne wrote:
> You keep proposing adding /bin/foo -> /usr/bin/foo symbolic links via
> maintainer scripts.
I'm not proposing this! I'm trying to *not* need to do that in any more
packages, and instead do usrmerge or equivalent, so that individual
packages' maintainers don't have to take per-package action to move
their files from /bin,/sbin,/lib* into /usr while creating compatibility
symlinks for non-merged-/usr systems.
However, I know Guillem and some others object to that strategy, so I'm
trying to also be clear about which of the fixes that are necessary with
usrmerge would be equally necessary for a symlink-farm-based strategy,
if people who prefer a symlink-farm-based strategy gain consensus for
that strategy.
Exactly how the symlinks in a symlink-farm-based strategy are created
is orthogonal to whether packages need to avoid hard-coding (e.g.) /bin/env
or /usr/bin/sh, in filesystem layouts where both paths with and without /usr
exist, which would break the installation of that package onto the traditional
filesystem layout where only /usr/bin/env and /bin/sh exist.
I agree that if a symlink-farm-based strategy is used, then delegating the
creation of the individual symlinks to individual packages' maintainer
scripts has practical problems, and it would be better to centralize the
creation of those symlinks (somehow). I think it's up to the people who
want to generate symlink farms to solve that problem.
Note that what the Technical Committee resolved as the desired state
is merged /usr with aliasing symlinks such as /bin -> usr/bin, not a
symlink farm with individual symlinks such as /bin/sh -> /usr/bin/sh,
precisely because we are concerned about the number of "moving parts"
involved in setting up a symlink farm. (Speaking for myself here, not
for the TC, but I don't think I'm misrepresenting anyone's position on
the symlink farm approach by saying this.)
> The collateral damage of the merged-/usr
> work to the work I'm interested in is huge.
In this specific case, I think the thing you're having a problem with is
the gradual, file-by-file migration of executables into /usr by individual
packages and individual packages' maintainers. That's not merged-/usr:
merged-/usr does the migration all at once, by creating the aliasing
symlinks (and then we can clean up the contents of data.tar.* to put all
/usr-like files below /usr at our leisure, during the next release cycle,
without needing maintainer script glue).
The aliasing symlinks create problems for dpkg, as Guillem has documented
elsewhere, and as a result some people are pursuing a symlink-farm-based
alternative to the aliasing symlinks. If that symlink-farm-based approach
is taken, then yes, we will need either a centralized mechanism to
construct those symlink farms, or a lot of maintainer script glue
(and, again, the Technical Committee's recommendation was to not do that).
The packages that needed maintainer-script changes *before* merged-/usr,
in order to enable merged-/usr, are those that previously shipped files
at both /foo and /usr/foo in their data.tar.*, such as
coreutils (<< 8.24-1) for /{usr/,}bin/touch. The reason they need
maintainer script code is that we still support non-merged-/usr systems;
their maintainer scripts are a no-op on merged-/usr systems, so if the
bookworm release only supported merged-/usr, then their maintainer
script code could disappear during the bookworm+1 cycle.
I agree that *those* maintainer scripts are creating extra work for
people working on DPKG_ROOT and similar things, and would not have been
necessary if we had not gone in the direction of merged-/usr in around
2016. If we can make those unnecessary, or more declarative, then that
would be a good direction.
smcv
[toc] | [prev] | [next] | [standalone]
| From | "Theodore Ts'o" <tytso@mit.edu> |
|---|---|
| Date | 2021-08-19 16:50 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CNRwK-2nV-9@gated-at.bofh.it> |
| In reply to | #101169 |
On Thu, Aug 19, 2021 at 11:17:17AM +0100, Simon McVittie wrote:
> In this specific case, I think the thing you're having a problem with is
> the gradual, file-by-file migration of executables into /usr by individual
> packages and individual packages' maintainers. That's not merged-/usr:
> merged-/usr does the migration all at once, by creating the aliasing
> symlinks (and then we can clean up the contents of data.tar.* to put all
> /usr-like files below /usr at our leisure, during the next release cycle,
> without needing maintainer script glue).
FWIW, from following the discussion, I've become more and more
convinced that a symlink farm is *not* the right answer, regardless of
whether it is done centrally or via individual packages moving files
and created symlinks if necessary in individual maintainer scripts.
The symlink farm idea seems to be pushed by the dpkg team, because
it's clear that supprorting directory aliasing by having /bin ->
usr/bin, /lib -> /usr/lib, etc., top-level symlinks does create more
work for the dpkg team, and they seem to be put off by the fact that
they hadn't agreed to do that work, and they appear to claim that they
weren't consulted in advance.
But if we are going to follow how Fedora, Solaris, etc, have been
moving elimitating the traditional /{bin,sbin,lib} and
/usr/{bin,sbin,lib} split, directory aliasing the way Fedora, Solaris,
etc. have done things is the only way to go.
Perhaps the dpkg team should have been consulted earlier, and if they
could have convincingly argued that this was a show stopper, or they
had demanded that someone else should have provided the engineering
effort to make dpkg handle the directory aliasing *first*, perhaps we
shouldn't have even stated in the /{bin,sbin,lib} ->
/usr/{bin,sbin,lib} unification journey, despite the fact that all of
the other distributions have gone down that path.
Speaking personally, I'm not super excited about /usr unification.
But then again, I don't work on projects such as embedded systems,
containerized systems, etc., which seem to benefit from /usr
unification, and there *is* value in being similar to other Linux
distributions.
In any case, that's water on the bridge. We are where we are, and
stopping midway through the /usr unification journey would be a far
worse outcome. And given that we've already lost the benefits of the
split /usr architecture (specifically, the ability to boot without
/usr being mounted, which I recognize is not as useful in the 21st
century) --- we should push on and finish the job.
Given that symlink farms have all sorts of downsides, the best path
foward seems to be to teach dpkg about the top-level directory
aliasing, and simply handling this appropriately. Issues such as the
/bin/sh vs. /usr/bin/sh unification causing problems with /etc/shells
is an issue all distributions have to deal with anyway, and we can
look to see how they have handled it.
Cheers,
- Ted
[toc] | [prev] | [next] | [standalone]
| From | Simon Richter <sjr@debian.org> |
|---|---|
| Date | 2021-08-19 22:50 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CNX97-5Yo-3@gated-at.bofh.it> |
| In reply to | #101178 |
[Multipart message — attachments visible in raw view] — view raw
Hi,
On 8/19/21 4:45 PM, Theodore Ts'o wrote:
> FWIW, from following the discussion, I've become more and more
> convinced that a symlink farm is *not* the right answer, regardless of
> whether it is done centrally or via individual packages moving files
> and created symlinks if necessary in individual maintainer scripts.
I think no one likes that idea, but it's the only solution that doesn't
immediately fail because it requires a dpkg update that hasn't shipped
with the current stable release, breaks local packages (kernel modules,
firmware, site-wide systemd configuration), or both.
The dpkg team are rightfully skeptical about introducing a policy
decision into the codebase, especially as the next dist-upgrade that
users are going to perform will upgrade dpkg somewhere in the middle of
the process, after several of its dependencies, which are precisely the
packages affected. You can't change default behavior here, you can't
introduce a new critical control field because it would create a
Depends/Pre-Depends loop, ...
What *could* be done in dpkg is to change the policy for replacing a
directory with a symlink. Currently, those entries are dropped, and the
comment next to the code responsible for that suggests that the most
common scenario where that would be seen were broken packages where
someone swapped source and destination while creating a symlink.
But: a new policy would still have to honor file conflicts. The /lib
directory cannot be replaced with a symlink until all packages that ship
a directory here are gone. Because /lib/ld-linux.so.2 is part of the
ABI, that cannot happen on its own, so we can probably narrow this down
to "until all packages that ship regular files below /lib are gone."
As I understand it, that is where the symlink farming approach comes
from: when the other packages move their regular files out of the way
and replace them by symlinks, we have a criterion by which we can decide
that the entire hierarchy can be replaced by a symlink.
We still need a mechanism in either dpkg or a package handling the
transition that actually performs this operation. If we can do this in a
package without touching dpkg, then IMO that would be preferable, but in
either case that mechanism needs to be defined first.
> Speaking personally, I'm not super excited about /usr unification.
> But then again, I don't work on projects such as embedded systems,
> containerized systems, etc., which seem to benefit from /usr
> unification, and there *is* value in being similar to other Linux
> distributions.
In my embedded projects, unification is counterproductive, because the
initramfs effectively takes on the functionality of the root filesystem,
except it cannot be modified in-place anymore with dpkg, and instead I
need a script that copies relevant files, follows dependencies and then
creates a compressed read-only root filesystem I can use for early boot.
That is about as convenient as using cramfs as the root filesystem,
except it needs a lot more memory, and I cannot prepare this on the host.
Starting systemd without /usr, /proc and /sys mounted has been broken
for ages, so booting without an initramfs simply does not work anyway there.
With sysvinit, it still mostly works, although some programs (also
mostly from the systemd ecosystem) fail before /usr is mounted as they
are missing libraries.
My expectation is that systemd will take over initramfs generation
during the next release cycle, that might make the situation a bit more
bearable as we can then reuse dependency information from units instead
of having a shell script recreate it using heuristics.
Right now, a kernel update on a 150 MHz NiosII CPU takes several hours
because the initramfs rebuild is just so slow, so for embedded systems,
Debian as it is is close to unusable anyway and I believe embedded
systems vendors have jumped ship a while ago. I have.
Simon
[toc] | [prev] | [next] | [standalone]
| From | "Theodore Ts'o" <tytso@mit.edu> |
|---|---|
| Date | 2021-08-20 02:00 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CO06Z-7L4-7@gated-at.bofh.it> |
| In reply to | #101184 |
On Thu, Aug 19, 2021 at 10:39:45PM +0200, Simon Richter wrote: > > I think no one likes that idea, but it's the only solution that doesn't > immediately fail because it requires a dpkg update that hasn't shipped with > the current stable release, breaks local packages (kernel modules, firmware, > site-wide systemd configuration), or both. This could be solved if we could somehow require dpkg to be updated before any other packages during the the next update, no? Breaking this constraint means that we can't make "apt-get dist-update" work seemlessly --- but what if we were to change the documented procedure for doing a major update? That's not ideal, granted, but how does that compare against the other alternatives? - Ted P.S. I had a vague memory that there was some update in the long distant past where we did require a manual upgrade of dpkg first. Or is my memory playing tricks on me? I do know that a manual update of dpkg is the first step in a crossgrade....
[toc] | [prev] | [next] | [standalone]
| From | Craig Small <csmall@debian.org> |
|---|---|
| Date | 2021-08-20 02:40 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CO0JH-8di-9@gated-at.bofh.it> |
| In reply to | #101188 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, 20 Aug 2021 at 09:56, Theodore Ts'o <tytso@mit.edu> wrote: > P.S. I had a vague memory that there was some update in the long > distant past where we did require a manual upgrade of dpkg first. Or > is my memory playing tricks on me? I do know that a manual update of > dpkg is the first step in a crossgrade.... > There was an instance of this. I cannot remember if it was the libc4/a.out or something to do with libstdc but it was library-related and a bit of a pain for end-users. In any case, it was not an ideal situation or something we should aim for. - Craig
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2021-08-20 12:30 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CO9WG-5Jd-3@gated-at.bofh.it> |
| In reply to | #101188 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, 2021-08-19 at 19:55 -0400, Theodore Ts'o wrote: > On Thu, Aug 19, 2021 at 10:39:45PM +0200, Simon Richter wrote: > > > > I think no one likes that idea, but it's the only solution that doesn't > > immediately fail because it requires a dpkg update that hasn't shipped with > > the current stable release, breaks local packages (kernel modules, firmware, > > site-wide systemd configuration), or both. > > This could be solved if we could somehow require dpkg to be updated > before any other packages during the the next update, no? > > Breaking this constraint means that we can't make "apt-get > dist-update" work seemlessly --- but what if we were to change the > documented procedure for doing a major update? > > That's not ideal, granted, but how does that compare against the other > alternatives? > > - Ted > > P.S. I had a vague memory that there was some update in the long > distant past where we did require a manual upgrade of dpkg first. Or > is my memory playing tricks on me? I do know that a manual update of > dpkg is the first step in a crossgrade.... An update to dpkg is not _required_. It might be very strongly _desired_ which is a perfectly legitimate stance to take, but it is not technically required, otherwise we couldn't have been shipping with merged-usr as default in new installations of Buster and Bullseye for 2+ years, we could not have been installing usrmerge in older installations for 2+ years, and Ubuntu would not exist anymore since legacy split-usr is discontinued and even older installations are being forcibly converted. So continuing to live with this minor ~20 years old dpkg bug as we've been doing for years is a valid option - one that some might very, very strongly dislike and argue against which is again perfectly legitimate, but it is de-facto an option nonetheless, because it's the actual status quo for 2+ years. -- Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Philip Hands <phil@hands.com> |
|---|---|
| Date | 2021-08-20 15:10 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <COcrw-7ue-25@gated-at.bofh.it> |
| In reply to | #101199 |
[Multipart message — attachments visible in raw view] — view raw
Luca Boccassi <bluca@debian.org> writes: > On Thu, 2021-08-19 at 19:55 -0400, Theodore Ts'o wrote: >> On Thu, Aug 19, 2021 at 10:39:45PM +0200, Simon Richter wrote: >> > >> > I think no one likes that idea, but it's the only solution that doesn't >> > immediately fail because it requires a dpkg update that hasn't shipped with >> > the current stable release, breaks local packages (kernel modules, firmware, >> > site-wide systemd configuration), or both. >> >> This could be solved if we could somehow require dpkg to be updated >> before any other packages during the the next update, no? >> >> Breaking this constraint means that we can't make "apt-get >> dist-update" work seemlessly --- but what if we were to change the >> documented procedure for doing a major update? >> >> That's not ideal, granted, but how does that compare against the other >> alternatives? >> >> - Ted >> >> P.S. I had a vague memory that there was some update in the long >> distant past where we did require a manual upgrade of dpkg first. Or >> is my memory playing tricks on me? I do know that a manual update of >> dpkg is the first step in a crossgrade.... > > An update to dpkg is not _required_. It might be very strongly > _desired_ which is a perfectly legitimate stance to take, but it is not > technically required, otherwise we couldn't have been shipping with > merged-usr as default in new installations of Buster and Bullseye for > 2+ years, we could not have been installing usrmerge in older > installations for 2+ years, and Ubuntu would not exist anymore since > legacy split-usr is discontinued and even older installations are being > forcibly converted. So continuing to live with this minor ~20 years old > dpkg bug as we've been doing for years is a valid option - one that > some might very, very strongly dislike and argue against which is again > perfectly legitimate, but it is de-facto an option nonetheless, because > it's the actual status quo for 2+ years. Well, quite -- we seem to have had predictions of the sky falling as a result of usrmerge and/or merged-/usr, but if it is falling it's doing it remarkably slowly. I've been paying attention to this for a while, what with being on the TC up until just before the unanimous decision (which I fully support). I'm as sure as one can be about the future that if in 20 years I am still around to type this into a supported Debian system: [ $(stat -Lc %i /bin) != $(stat -Lc %i /usr/bin) ] && cowsay Surprise! I will not see a talking cow[1]. I'm also pretty sure that the 2041 version of dpkg will either be completely relaxed about having /bin be a symlink, or we'll be using something else by then. That being the case, we might as well get on with it rather than trying to pretend that filling everyone's disks with shedloads of symlinks for a while in-between now and then is a useful thing to do. Cheers, Phil. [1] unless of course there's a reason to use some sort of bind-mount or other filesystem trickery that's invented in the interim to achieve the same result. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <wouter@debian.org> |
|---|---|
| Date | 2021-08-21 10:30 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <COuy5-1If-5@gated-at.bofh.it> |
| In reply to | #101199 |
On Fri, Aug 20, 2021 at 11:21:55AM +0100, Luca Boccassi wrote:
> On Thu, 2021-08-19 at 19:55 -0400, Theodore Ts'o wrote:
> > On Thu, Aug 19, 2021 at 10:39:45PM +0200, Simon Richter wrote:
> > >
> > > I think no one likes that idea, but it's the only solution that doesn't
> > > immediately fail because it requires a dpkg update that hasn't shipped with
> > > the current stable release, breaks local packages (kernel modules, firmware,
> > > site-wide systemd configuration), or both.
> >
> > This could be solved if we could somehow require dpkg to be updated
> > before any other packages during the the next update, no?
> >
> > Breaking this constraint means that we can't make "apt-get
> > dist-update" work seemlessly --- but what if we were to change the
> > documented procedure for doing a major update?
> >
> > That's not ideal, granted, but how does that compare against the other
> > alternatives?
> >
> > - Ted
> >
> > P.S. I had a vague memory that there was some update in the long
> > distant past where we did require a manual upgrade of dpkg first. Or
> > is my memory playing tricks on me? I do know that a manual update of
> > dpkg is the first step in a crossgrade....
>
> An update to dpkg is not _required_. It might be very strongly
> _desired_ which is a perfectly legitimate stance to take, but it is not
> technically required, otherwise we couldn't have been shipping with
> merged-usr as default in new installations of Buster and Bullseye for
> 2+ years, we could not have been installing usrmerge in older
> installations for 2+ years, and Ubuntu would not exist anymore since
> legacy split-usr is discontinued and even older installations are being
> forcibly converted. So continuing to live with this minor ~20 years old
> dpkg bug as we've been doing for years is a valid option - one that
> some might very, very strongly dislike and argue against which is again
> perfectly legitimate, but it is de-facto an option nonetheless, because
> it's the actual status quo for 2+ years.
It bothers me that you believe "we've been doing this for a while and it
didn't cause any problems, so let's just continue doing things that way
even if the people who actually wrote the damn code say that path is
littered with minefields and they're scared of what could happen when we
finish the tranition this way" is a valid strategy. It goes against
everything I was taught to do to write reliable software.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
[toc] | [prev] | [next] | [standalone]
Page 5 of 13 — ← Prev page 1 … 3 4 [5] 6 7 … 13 Next page →
Back to top | Article view | linux.debian.devel
csiph-web