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 10 of 13 — ← Prev page 1 … 8 9 [10] 11 12 13 Next page →
| From | Richard Laager <rlaager@debian.org> |
|---|---|
| Date | 2021-08-27 21:20 +0200 |
| Subject | Re: next steps after usrunmess |
| Message-ID | <CQPyq-X1-9@gated-at.bofh.it> |
| In reply to | #101422 |
[Multipart message — attachments visible in raw view] — view raw
On 8/27/21 10:20 AM, Theodore Ts'o wrote: > Does someone need to create patches to dpkg which attempt to teach it > that /bin/foo and /usr/bin/foo are the same file, if there exists a > symlink from /bin to usr/bin? Yes. I can't speak to the dpkg internals, but conceptually, this seems like the right thing to do. Even if we eliminated usrmerge entirely, I'm not sure what's harmful about dpkg canonicalizing filenames. In fact, it seems very much like the right thing to do. So unless the patch is very invasive, I don't see why one would object to this change on its own. > And then with some kind of process, > maybe with the blessing of the technical committee, upload it as an > NMU over the objections of the dpkg developers if they continue to > refuse to engage with solutions that proceed forward with > /usr-unification? Yes. If the dpkg maintainer does not accept a reasonable patch, then this may need to be presented to the TC to overrule him, which requires a 3:1 TC majority. One might argue the existing TC decision implies this, but the least ambiguous procedural option would be to have the TC explicitly overrule the maintainer once a specific implementation is available. It is my view that the usrunmess utility also needs to be dropped before the bookworm release. That quite clearly follows from the existing TC decision, which is that only the merged-usr layout is supported, so I don't think that needs further TC action. However, I think removing that utility should wait until such time as we have the other issues reasonably resolved. > Should a single DD have the > power to overturn a techical committee because they are the maintainer > of a highly important package? No. This is settled in the Debian constitution. If a DD wishes to override the TC, they need to propose a GR. -- Richard
[toc] | [prev] | [next] | [standalone]
| From | Ansgar <ansgar@43-1.org> |
|---|---|
| Date | 2021-08-22 11:10 +0200 |
| Subject | Re: merged-/usr vs. partially-symlink-farmed-root |
| Message-ID | <COREm-7Vg-21@gated-at.bofh.it> |
| In reply to | #101263 |
Hi Guillem, On Sun, 2021-08-22 at 00:11 +0200, Guillem Jover wrote: > There was talk about the huge amount of symlinks required in a > symlink > farm setting, but that might have been true for a scenario where > those > symlinks would have been handled automatically and transparently. To get a filesystem layout equivalent to merged-/usr via symlinks farming *every* package shipping files in at least /usr/bin, /usr/sbin and possibly some of /usr/lib would need to include symlinks in /bin, /sbin, /lib. This would affect far more packages than updating the packages currently shipping files in /bin, /sbin and /lib* to ship these under /usr instead. Note that on a merged-/usr system it is fine, and will be fine forever, to use /bin/python3 instead of /usr/bin/python3. If this is not done, the layouts are even more different. So they should be named differently to avoid people confusing them as minor variants of the same: maybe merged-/usr and partially-symlink-farmed- root (as not all compatibility symlinks exist). > The huge majority of files under /lib* (which is the actual bulk of > them) > should require no symlink farms. Many of the ones under /bin and > /sbin > (we are talking about around 240 packages here) might be switchable > w/o > compat symlinks after careful consideration (or not…), many of the > ones > that require symlinks would need these just for a period of time, Removing any symlink will cause software to break. There was recently one such instance with `run-parts` getting moved to /usr/bin. Is your proposal to repeat this for every binary in /bin and /sbin (except possibly some selected ones) at one point in time? There seems no realistic way to find/fix all software affected by this beforehand, especially software outside of Debian. What is your proposal to handle this? Note that this breakage only happens with your newly proposed partially-symlink-farmed-root filesystem layout that you propose instead of merged-/usr. > and > only a handful would remain (the ones that are part of standard > interfaces, which I'd expect would be mostly shells?). I think the > amount > of symlinks currently provided by f.ex. lvm2 and e2fsprogs combined > would > amount to more symlinks than what we would eventually end up with > TBH. So your proposal is to adopt a partially-symlink-farmed-root layout and never switch to merged-/usr? Sure, in that case SuSE failing to move from partially-symlink-farmed-root to merged-/usr is not an argument against that. But it still is a good argument against adopting partially-symlink-farmed-root as a way to get to merged-/usr. What are the advantages to moving to a new filesystem layout used only by Debian which introduces incompatibilities with other distributions? Are there further disadvantages we have not yet found? > Luca posted a mess of disinformation. [...] > Or there's the following for example: > > > IN particular, most systems are usrmerged today, and while these > > bugs > > are annoying, many people get along just fine. > > That would imply that most people have either gone out of their way > to > explicitly install and run usrmerge or they have reinstalled from > scratch. I cannot believe the first to be of any significance, the > second would put into question why we bother supporting release > upgrades > (after all many other distros do not support that, we perhaps should > catch up with what the rest of the world is doing!). Various distributions outside of Debian seem to recommend installing usrmerge on upgrade, for example Ubuntu or Linux Mint, with Ubuntu also pulling in the usrmerge package on upgrades by default. So by now there likely is a significant population of such users. I also don't see people doing new installations as a problem: people not only using Debian on existing installations that might be a decade old, but also deploying it on new systems is a good thing. I don't think people doing so has any implications to question supporting upgrades or not. (Besides totally new systems there are of course other valid reasons to start from a clean slate instead of upgrading an existing system such as having a documented state or just automated deployment.) To be honest the conjecture that the number of people having installed Debian or Ubuntu or other Debian-based distributions in the last few years is insignificant and can be totally ignored feels rather far fetched just to support an outcome you want to see true. We would have much, much larger problems for the future of Debian and Debian-based distributions than merged-/usr if this was true. So if you have any support for this claim, I'm interested in seeing it. Ansgar
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2021-08-22 12:30 +0200 |
| Subject | Re: merged-/usr vs. partially-symlink-farmed-root |
| Message-ID | <COSTL-8B-1@gated-at.bofh.it> |
| In reply to | #101269 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, 2021-08-22 at 11:08 +0200, Ansgar wrote: > Hi Guillem, > > On Sun, 2021-08-22 at 00:11 +0200, Guillem Jover wrote: > > There was talk about the huge amount of symlinks required in a > > symlink > > farm setting, but that might have been true for a scenario where > > those > > symlinks would have been handled automatically and transparently. > > To get a filesystem layout equivalent to merged-/usr via symlinks > farming *every* package shipping files in at least /usr/bin, > /usr/sbin > and possibly some of /usr/lib would need to include symlinks in /bin, > /sbin, /lib. This would affect far more packages than updating the > packages currently shipping files in /bin, /sbin and /lib* to ship > these under /usr instead. > > Note that on a merged-/usr system it is fine, and will be fine > forever, > to use /bin/python3 instead of /usr/bin/python3. > > If this is not done, the layouts are even more different. So they > should be named differently to avoid people confusing them as minor > variants of the same: maybe merged-/usr and partially-symlink-farmed- > root (as not all compatibility symlinks exist). > > > The huge majority of files under /lib* (which is the actual bulk of > > them) > > should require no symlink farms. Many of the ones under /bin and > > /sbin > > (we are talking about around 240 packages here) might be switchable > > w/o > > compat symlinks after careful consideration (or not…), many of the > > ones > > that require symlinks would need these just for a period of time, > > Removing any symlink will cause software to break. > > There was recently one such instance with `run-parts` getting moved > to > /usr/bin. Is your proposal to repeat this for every binary in /bin > and > /sbin (except possibly some selected ones) at one point in time? > There seems no realistic way to find/fix all software affected by > this > beforehand, especially software outside of Debian. What is your > proposal to handle this? > > Note that this breakage only happens with your newly proposed > partially-symlink-farmed-root filesystem layout that you propose > instead of merged-/usr. > > > and > > only a handful would remain (the ones that are part of standard > > interfaces, which I'd expect would be mostly shells?). I think the > > amount > > of symlinks currently provided by f.ex. lvm2 and e2fsprogs combined > > would > > amount to more symlinks than what we would eventually end up with > > TBH. > > So your proposal is to adopt a partially-symlink-farmed-root layout > and > never switch to merged-/usr? Sure, in that case SuSE failing to move > from partially-symlink-farmed-root to merged-/usr is not an argument > against that. But it still is a good argument against adopting > partially-symlink-farmed-root as a way to get to merged-/usr. > > What are the advantages to moving to a new filesystem layout used > only > by Debian which introduces incompatibilities with other > distributions? > > Are there further disadvantages we have not yet found? > > > Luca posted a mess of disinformation. > [...] > > Or there's the following for example: > > > > > IN particular, most systems are usrmerged today, and while these > > > bugs > > > are annoying, many people get along just fine. > > > > That would imply that most people have either gone out of their way > > to > > explicitly install and run usrmerge or they have reinstalled from > > scratch. I cannot believe the first to be of any significance, the > > second would put into question why we bother supporting release > > upgrades > > (after all many other distros do not support that, we perhaps > > should > > catch up with what the rest of the world is doing!). > > Various distributions outside of Debian seem to recommend installing > usrmerge on upgrade, for example Ubuntu or Linux Mint, with Ubuntu > also > pulling in the usrmerge package on upgrades by default. So by now > there > likely is a significant population of such users. > > I also don't see people doing new installations as a problem: people > not only using Debian on existing installations that might be a > decade > old, but also deploying it on new systems is a good thing. I don't > think people doing so has any implications to question supporting > upgrades or not. (Besides totally new systems there are of course > other valid reasons to start from a clean slate instead of upgrading > an > existing system such as having a documented state or just automated > deployment.) > > To be honest the conjecture that the number of people having > installed > Debian or Ubuntu or other Debian-based distributions in the last few > years is insignificant and can be totally ignored feels rather far > fetched just to support an outcome you want to see true. We would > have > much, much larger problems for the future of Debian and Debian-based > distributions than merged-/usr if this was true. So if you have any > support for this claim, I'm interested in seeing it. > > Ansgar Indeed it seems a strange claim to make - new users and new machines do exist. And for non-user deployments (cloud, servers) installations are common workflow too. Do we have statistics to show the number of downloads of Debian images for Buster and Bullseye? I tried (briefly) looking, but couldn't find any. I assume Canonical does not divulge these numbers for business reasons, but happy to be disproven on that. -- Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Marvin Renich <mrvn@renich.org> |
|---|---|
| Date | 2021-08-22 18:40 +0200 |
| Subject | Re: merged-/usr vs. partially-symlink-farmed-root |
| Message-ID | <COYFQ-3HX-9@gated-at.bofh.it> |
| In reply to | #101269 |
* Ansgar <ansgar@43-1.org> [210822 05:08]: > Hi Guillem, > > On Sun, 2021-08-22 at 00:11 +0200, Guillem Jover wrote: > > There was talk about the huge amount of symlinks required in a > > symlink farm setting, but that might have been true for a scenario > > where those symlinks would have been handled automatically and > > transparently. > > To get a filesystem layout equivalent to merged-/usr via symlinks > farming *every* package shipping files in at least /usr/bin, /usr/sbin > and possibly some of /usr/lib would need to include symlinks in /bin, > /sbin, /lib. This would affect far more packages than updating the > packages currently shipping files in /bin, /sbin and /lib* to ship > these under /usr instead. It is true that for a symlink-farm-usr-merge system to be strictly equivalent to a symlink-dir-usr-merge system, many packages that never had /bin/foo but had /usr/bin/foo would have to add a symlink /bin/foo, however this is clearly unnecessary. The problem that the symlink farm is solving is that scripts (distributed or user-written) that depend on /bin/foo need to continue to work on a partially merged system. A previous message (already deleted, so I'm not sure from whom) clearly identified 240 packages (number pulled from memory, so might be off) that would have to put symlinks in /bin and /sbin for the symlink-farm-usr-merge strategy to work. The amount of work is orders of magnitude less than you are representing. There is no need for the symlink-farm to exactly match the symlink-dir solution. The union of systems during the symlink-farm merge and systems after the merge is complete can _only_ count on /bin/foo existing if it existed before the merge was started. There is no need for anything else (wrt /bin/foo existing). ...Marvin
[toc] | [prev] | [next] | [standalone]
| From | Simon Richter <sjr@debian.org> |
|---|---|
| Date | 2021-08-22 19:00 +0200 |
| Subject | Re: merged-/usr vs. partially-symlink-farmed-root |
| Message-ID | <COYZc-3Py-23@gated-at.bofh.it> |
| In reply to | #101284 |
Hi,
On 22.08.21 18:29, Marvin Renich wrote:
> The amount of work is orders of magnitude less than you are
> representing. There is no need for the symlink-farm to exactly match
> the symlink-dir solution. The union of systems during the symlink-farm
> merge and systems after the merge is complete can _only_ count on
> /bin/foo existing if it existed before the merge was started. There is
> no need for anything else (wrt /bin/foo existing).
I would expect people to start using /bin/python at some point just
because they can.
Simon
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2021-08-22 23:30 +0200 |
| Subject | Re: merged-/usr vs. partially-symlink-farmed-root |
| Message-ID | <CP3cu-6Ad-9@gated-at.bofh.it> |
| In reply to | #101284 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, 2021-08-22 at 12:29 -0400, Marvin Renich wrote: > * Ansgar <ansgar@43-1.org> [210822 05:08]: > > Hi Guillem, > > > > On Sun, 2021-08-22 at 00:11 +0200, Guillem Jover wrote: > > > There was talk about the huge amount of symlinks required in a > > > symlink farm setting, but that might have been true for a > > > scenario > > > where those symlinks would have been handled automatically and > > > transparently. > > > > To get a filesystem layout equivalent to merged-/usr via symlinks > > farming *every* package shipping files in at least /usr/bin, > > /usr/sbin > > and possibly some of /usr/lib would need to include symlinks in > > /bin, > > /sbin, /lib. This would affect far more packages than updating the > > packages currently shipping files in /bin, /sbin and /lib* to ship > > these under /usr instead. > > It is true that for a symlink-farm-usr-merge system to be strictly > equivalent to a symlink-dir-usr-merge system, many packages that > never > had /bin/foo but had /usr/bin/foo would have to add a symlink > /bin/foo, > however this is clearly unnecessary. The problem that the symlink > farm > is solving is that scripts (distributed or user-written) that depend > on > /bin/foo need to continue to work on a partially merged system. A > previous message (already deleted, so I'm not sure from whom) clearly > identified 240 packages (number pulled from memory, so might be off) > that would have to put symlinks in /bin and /sbin for the > symlink-farm-usr-merge strategy to work. > > The amount of work is orders of magnitude less than you are > representing. There is no need for the symlink-farm to exactly match > the symlink-dir solution. The union of systems during the symlink- > farm > merge and systems after the merge is complete can _only_ count on > /bin/foo existing if it existed before the merge was started. There > is > no need for anything else (wrt /bin/foo existing). > > ...Marvin The point of the migration is that /usr/bin will be identical to /bin, etc. If they are not identical, then it's not usrmerge as it is understood and has been adopted by many upstreams for a decade, it's something else that is incompatible with it. -- Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | "Theodore Ts'o" <tytso@mit.edu> |
|---|---|
| Date | 2021-08-23 00:20 +0200 |
| Subject | Re: merged-/usr vs. partially-symlink-farmed-root |
| Message-ID | <CP3YR-78P-1@gated-at.bofh.it> |
| In reply to | #101293 |
On Sun, Aug 22, 2021 at 10:24:56PM +0100, Luca Boccassi wrote:
> The point of the migration is that /usr/bin will be identical to /bin,
> etc. If they are not identical, then it's not usrmerge as it is
> understood and has been adopted by many upstreams for a decade, it's
> something else that is incompatible with it.
I'll note that people on this thread are using usrmerge in different
senses of the word.
For simplicity's sake, what I've tried to do in my posts is to refer
to "usrmerge" as meaning the creations of top-level symlinks at
/{bin,lib,sbin} pointing /usr//{bin,lib,sbin}. This is the specific
proposal made here:
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
... and in Debian, see:
https://wiki.debian.org/UsrMerge
So I think there is some justification to using to usrmerge only to
refer to the top-level symlinks approach.
A more general term might be "/usr unification", quoting from a
2012(!) LWN article:
"/usr unification" (or simply "usrmove") is the idea of moving
the contents of /bin, /lib, and related root-level directories
into their equivalents under /usr.
- https://lwn.net/Articles/483921/
After moving the contents of /{bin,lib,sbin}/* to their equivalents
under /usr, the next question is whether we stop things from breaking?
By using top-level sytmlinks, which many call "usrmerge", or creating
symlink farms in the directories /{bin,lib,sbin}, for which I try to
use the more awkward construction, "/usr unification via symlink
farms"?
Admittedly, "/usr unification via symlink farms" is awkward, but I've
been hoping we can declare consensus that using symlink farms is
undersirable way of trying to achieve /usr unification, since it
wastes a lot of on-disk inodes, and there is complexity involved in
needing to keep the symlink farm up-to-date as new files are created
in /usr/{bin,lib,sbin}.
But in any case, perhaps it would simplfy the discussion if we try to
stick with consistent terminology? So what if we were to use usrmerge
to unambiguously mean achieving /usr unification via top-level
/{bin,lib,sbin} to /usr/{bin,lib,sbin} and considering symlink farms
as being another (although IMHO, inferior) way accomplishing the goal
of /usr/ unification?
- Ted
[toc] | [prev] | [next] | [standalone]
| From | Ansgar <ansgar@43-1.org> |
|---|---|
| Date | 2021-08-22 23:30 +0200 |
| Subject | Re: merged-/usr vs. partially-symlink-farmed-root |
| Message-ID | <CP3ct-6Ad-7@gated-at.bofh.it> |
| In reply to | #101284 |
Hi, On Sun, 2021-08-22 at 12:29 -0400, Marvin Renich wrote: > * Ansgar <ansgar@43-1.org> [210822 05:08]: > > To get a filesystem layout equivalent to merged-/usr via symlinks > > farming *every* package shipping files in at least /usr/bin, > > /usr/sbin > > and possibly some of /usr/lib would need to include symlinks in > > /bin, > > /sbin, /lib. This would affect far more packages than updating the > > packages currently shipping files in /bin, /sbin and /lib* to ship > > these under /usr instead. > > It is true that for a symlink-farm-usr-merge system to be strictly > equivalent to a symlink-dir-usr-merge system, many packages that > never > had /bin/foo but had /usr/bin/foo would have to add a symlink > /bin/foo, > however this is clearly unnecessary. No, it is required if we want users to be able to run scripts that use `#!/bin/python3` (or similar for other interpreters). Such scripts exist in the wild, they were not initially written on Debian. These would need Debian-specific patches to work on Debian. It is just the opposite of now having to patch software packaged in Debian to use /bin/rm instead of /usr/bin/rm (that also happens in the wild for software not developed on Debian). We also happen to miss such instances and needlessly make software buggy on Debian. Not having to worry about yet another small incompatibility between distributions is a nice feature. Ansgar
[toc] | [prev] | [next] | [standalone]
| From | Marvin Renich <mrvn@renich.org> |
|---|---|
| Date | 2021-08-23 16:40 +0200 |
| Subject | Re: merged-/usr vs. partially-symlink-farmed-root |
| Message-ID | <CPjhg-87Y-15@gated-at.bofh.it> |
| In reply to | #101294 |
* Ansgar <ansgar@43-1.org> [210822 17:29]: > Hi, > > On Sun, 2021-08-22 at 12:29 -0400, Marvin Renich wrote: > > * Ansgar <ansgar@43-1.org> [210822 05:08]: > > > To get a filesystem layout equivalent to merged-/usr via symlinks > > > farming *every* package shipping files in at least /usr/bin, > > > /usr/sbin and possibly some of /usr/lib would need to include > > > symlinks in /bin, /sbin, /lib. This would affect far more > > > packages than updating the packages currently shipping files in > > > /bin, /sbin and /lib* to ship these under /usr instead. > > > > It is true that for a symlink-farm-usr-merge system to be strictly > > equivalent to a symlink-dir-usr-merge system, many packages that > > never had /bin/foo but had /usr/bin/foo would have to add a symlink > > /bin/foo, however this is clearly unnecessary. > > No, it is required if we want users to be able to run scripts that use > `#!/bin/python3` (or similar for other interpreters). Such scripts > exist in the wild, they were not initially written on Debian. > > These would need Debian-specific patches to work on Debian. It is just > the opposite of now having to patch software packaged in Debian to use > /bin/rm instead of /usr/bin/rm (that also happens in the wild for > software not developed on Debian). We also happen to miss such > instances and needlessly make software buggy on Debian. > > Not having to worry about yet another small incompatibility between > distributions is a nice feature. Yet they cannot be counted on to work on Debian now, nor will they on non- or partially-merged systems. You are saying "the end result is thus, so the partially merged system must have this property." That does not follow. It is part of the impatience for a finished product that usually ends up with something less ideal than would be possible with a more patient approach. (And the symlink-dir approach appears to me to be driven primarily by impatience.) Anyone who has a '#!/bin/python3' script now, must ensure the link is there themselves, and that would not change in the middle of a symlink-farm transition, nor would it hinder such transition. I was initially in favor of the symlink-farm approach, because it is the correct technical solution. I have become convinced that the symlink-dir approach is the correct social solution (which is often, and I believe in this case it is, worse than the correct technical solution). I also believe that fixing dpkg to handle the general "symlink dir on file system where .deb has a real dir" case is useful for other cases. However, do not use bogus arguments such as the one above to try to make your point. It clutters the discussion with needless debunking. ...Marvin
[toc] | [prev] | [next] | [standalone]
| From | Ansgar <ansgar@43-1.org> |
|---|---|
| Date | 2021-08-23 17:20 +0200 |
| Subject | Re: merged-/usr vs. partially-symlink-farmed-root |
| Message-ID | <CPjTX-8O-11@gated-at.bofh.it> |
| In reply to | #101321 |
Hi Marvin, On Mon, 2021-08-23 at 10:29 -0400, Marvin Renich wrote: > Yet they cannot be counted on to work on Debian now, nor will they on > non- or partially-merged systems. You are saying "the end result is > thus, so the partially merged system must have this property." No. I am comparing end results from two different proposals. I am not talking about any intermediate state. There is no replacing /bin with a /bin -> /usr/bin symlink ever in the partially-symlink-farmed-root proposal. So you only get the symlinks provided explicitly in /bin by packages and, e.g., dash would ship forever a /bin/sh -> /usr/bin/sh symlink and this would be present on all systems. Only non-required symlinks like for, say, run-parts could be dropped. See [1] about "finishing the transition". [1]: https://lists.debian.org/debian-devel/2019/02/msg00321.html > Anyone who has a '#!/bin/python3' script now, must ensure the link is > there themselves, and that would not change in the middle of a > symlink-farm transition, nor would it hinder such transition. Yes, but where it would work once the transition to the new proposed layout differs between merged-/usr and partially-symlink-farmed-root (unless one does fully-symlink-farmed-root including symlinks for all binaries in /usr/bin and /usr/sbin, but that would be yet another different proposal). > However, do not use bogus arguments such as the one above to try to > maken your point. It clutters the discussion with needless > debunking. I think you misunderstand how the partially-symlink-farmed-root proposal is different from the merged-/usr proposal. Exactly to avoid such misunderstandings the partially-symlink-farmed-root proposal should not be named merged-/usr. Ansgar
[toc] | [prev] | [next] | [standalone]
| From | Marvin Renich <mrvn@renich.org> |
|---|---|
| Date | 2021-08-23 18:30 +0200 |
| Subject | Re: merged-/usr vs. partially-symlink-farmed-root |
| Message-ID | <CPkZI-Mi-5@gated-at.bofh.it> |
| In reply to | #101322 |
* Ansgar <ansgar@43-1.org> [210823 11:16]:
> Hi Marvin,
>
> On Mon, 2021-08-23 at 10:29 -0400, Marvin Renich wrote:
> > Yet they cannot be counted on to work on Debian now, nor will they on
> > non- or partially-merged systems. You are saying "the end result is
> > thus, so the partially merged system must have this property."
>
> No. I am comparing end results from two different proposals. I am not
> talking about any intermediate state.
>
> There is no replacing /bin with a /bin -> /usr/bin symlink ever in the
> partially-symlink-farmed-root proposal. So you only get the symlinks
> provided explicitly in /bin by packages and, e.g., dash would ship
> forever a /bin/sh -> /usr/bin/sh symlink and this would be present on
> all systems.
>
> Only non-required symlinks like for, say, run-parts could be dropped.
>
> See [1] about "finishing the transition".
>
> [1]: https://lists.debian.org/debian-devel/2019/02/msg00321.html
I did, indeed, miss this. I stand corrected; please accept my
apologies.
While I understand Guillem's rational, I believe that the effort to
clean up once there are only symlinks in /{,s}bin could be easily
automated and would technically be worth the effort (including code in
dpkg to recognize symlinks such as /bin/dash → /usr/bin/dash and mark
them in its database as "intentionally not placed on the filesystem").
However, at this point, I don't believe it is socially feasible to
continue down the symlink-farm path.
Again, I apologize for the misinformed argument.
...Marvin
[toc] | [prev] | [next] | [standalone]
| From | Tomas Pospisek <tpo2@sourcepole.ch> |
|---|---|
| Date | 2021-08-22 21:30 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CP1kn-5sn-5@gated-at.bofh.it> |
| In reply to | #101263 |
On 22.08.21 00:11, Guillem Jover wrote: > I'm personally just not seeing such consensus, despite the attempts of > some to make it pass as so. My perception is that this topic has become > such a black hole of despair, that people that take issue with it, are > simply stepping away. Possibly. But for me as one datapoint of N the amount and level of tricky technical detail is way beyond me, so I am standing on the sideline and watching the discussion and leaving the arguments to the experts. And I do not really care which solution will be chosen. I hope it will be one that doesn't break my system(s) too hard so I'll be able to ask a search engine and follow the hints and instructions. Wrt not caring much about which solution will be chosen: Debian has now passed through transitions where people were extremely (emotionally) involved. I wasn't consistently on the winning side: my preference would have been to keep it simple and to be able to fire up `vim` to debug some aspect of the boot system or services failing to start, but here we are, we've got systemd instead. So I had to adapt, to learn new stuff and the world did not end in fact I am OK with it. Could be that I am that single one DD with this perspective, or maybe not. In the end I think Debian is a do-o-cracy: we can decide whatever we want via TC or GR but unless there's someone willing to do the work all decisions won't matter. So it is my hope - in fact my conviction - that whoever does the work for the merged /usr will find a solution that won't trash my system(s) too badly and I'll find a way to fix'em. And if the scratch will itch too badly I might eventually even file a patch that will give others relief as well. From this same perspective: > Exhausted, > Guillem seeing you exhausted is sad. You do ****not**** need to carry the weight of this problem, of dpkg or of Debian. I believe Debian *will* find a way. Some way. Debian *does* have many capable and interested people. *Do* take care of yourself. Do make sure that working on dpkg is still enjoyable for you or whatever your motivation is. There's strictly no need you burning yourself out on this. You *can* take a step back an deinvest *yourself* from this. It is a technical and maybe a social problem but it is *not* *your* problem unless you let it be so. Huge respect and thanks for all your work this far! *t
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2021-08-19 12:50 +0200 |
| Subject | Re: testing for rootfs vs. /usr reproducibility regressions |
| Message-ID | <CNNMt-8jb-1@gated-at.bofh.it> |
| In reply to | #101165 |
On Thu, 19 Aug 2021 at 10:06:27 +0200, Helmut Grohne wrote:
> 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.
>
> 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.
Is this the scenario you're concerned about?
* We reach a point where every package in bookworm builds identically
(or with only non-/usr-related variation) in non-merged-/usr and
merged-/usr chroots, i.e. the bugs falling into classification
https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html
have all been fixed
* We deploy an automatic transition mechanism that makes all bookworm
installations, including chroots, convert to merged-/usr (for example,
making usrmerge transitively Essential would be one possible
implementation, although perhaps not the best one)
* Now our buildd chroots are all merged-/usr, and additionally we can
no longer easily test for /usr-related reproducibility
* The foo maintainer uploads foo_1.0 that has a regression, introducing a
*new* /usr-related unreproducibility (for example it might end up
hard-coding /usr/bin/sh when built in a merged-/usr environment, rather
than the /bin/sh that is correct for traditional environments, even
though earlier versions of foo did not have that bug)
* The regression is not detected because we can't easily test for it any more
* A user carries out a partial upgrade in which foo_1.0 is upgraded before
whatever part of the system is responsible for carrying out the transition
mechanism
* Now foo doesn't work on that user's system
I agree that's a potential failure mode, although the window for regression
is not necessarily very long (foo would have to regress after the automatic
transition is already in place).
> 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.
One way we could escape from this would be to observe that the earliest
point at which it is OK for package maintainers to rely on merged-/usr is
when the bookworm+1 development cycle opens, therefore it is OK to have
a mechanism for bookworm chroots/containers to be special-cased to opt out
from the merged-/usr transition, as long as those chroots/containers will
never be upgraded to bookworm+1 (because in practice we tend to discard
and re-bootstrap chroots/containers rather than upgrading them).
Conceptually, those chroots/containers are stuck in the "upgrade from
bullseye to bookworm almost but not quite complete" state, forever.
If desired, we could declare this to be formally unsupported, but
make reproducible-builds do it anyway, purely as a way to get test
coverage. This would be conceptually similar to the way people regularly
do archive rebuilds with a gcc that is not supported as the default yet,
in order to get the information we need before we can make it the default
- but in reverse, with the "old" configuration being the one that is
formally unsupported.
reproducible-builds could do something like this:
* for build1: do a merged-/usr chroot/container as (will become) usual
* for build2: bootstrap a chroot/container with --no-merged-usr, and set
whatever flag opts-out from the transition
or (matching what they do for buster/bullseye):
* bootstrap a chroot/container with --no-merged-usr
* for build1: use it as-is (opting out from the transition if necessary)
* for build2: enable the transition and let it happen, or install usrmerge
manually
Or, if the transition ends up being done during boot, either in the
initramfs or in normal user-space, then chroots/containers would
"naturally" not transition without manual action - similar to the way
chroots/containers don't pick up kernel or initramfs behaviour changes
like the changed default for /proc/sys/kernel/unprivileged_userns_clone
in bullseye, because their kernel is not their own.
smcv
[toc] | [prev] | [next] | [standalone]
| From | Helmut Grohne <helmut@subdivi.de> |
|---|---|
| Date | 2021-08-20 10:20 +0200 |
| Subject | Re: testing for rootfs vs. /usr reproducibility regressions |
| Message-ID | <CO7US-4xo-11@gated-at.bofh.it> |
| In reply to | #101170 |
Hi Simon, On Thu, Aug 19, 2021 at 11:49:22AM +0100, Simon McVittie wrote: > I agree that's a potential failure mode, although the window for regression > is not necessarily very long (foo would have to regress after the automatic > transition is already in place). Yes. You phrased it better, then I did. Thank you. The options you present to work around this sound plausible to me, but they do complicate the transition plan somewhat. In essence, we'll get two transition points. One for non-buildds and another for them. Helmut
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2021-08-20 12:40 +0200 |
| Subject | Re: testing for rootfs vs. /usr reproducibility regressions |
| Message-ID | <COa6m-5Mi-9@gated-at.bofh.it> |
| In reply to | #101194 |
On Fri, 20 Aug 2021 at 07:26:51 +0200, Helmut Grohne wrote:
> The options you present to work around this sound plausible to me, but
> they do complicate the transition plan somewhat. In essence, we'll get
> two transition points. One for non-buildds and another for them.
Maybe that, but what I was suggesting most recently was one transition
point for everything except reproducible-builds.org (and maybe other QA
infra), and one for reproducible-builds.org (and maybe other QA infra).
If we have reproducible-builds.org reporting merged-/usr vs. split-/usr
variation bugs like #949270, and we have fixed all known instances of
that variation, then it becomes a lot more viable to let buildd chroots
migrate to merged-/usr alongside end-user systems, because at that
point it no longer matters whether buildd chroots are merged-/usr or not
(and reproducible-builds.org would tell us about regressions that make
it matter again).
smcv
[toc] | [prev] | [next] | [standalone]
| From | Timothy M Butterworth <timothy.m.butterworth@gmail.com> |
|---|---|
| Date | 2021-08-20 23:40 +0200 |
| Subject | Re: testing for rootfs vs. /usr reproducibility regressions |
| Message-ID | <COkp4-3MQ-21@gated-at.bofh.it> |
| In reply to | #101201 |
All, Sorry I am a little late to this party so I have a new-be question, what is the point of merged-usr? It seems like a lot of work for a little reward, as the packages already work. Is there a legitimate benefit for changing all these file paths that I am missing? Thanks Tim
[toc] | [prev] | [next] | [standalone]
| From | Andy Smith <andy@strugglers.net> |
|---|---|
| Date | 2021-08-21 19:30 +0200 |
| Subject | Re: testing for rootfs vs. /usr reproducibility regressions |
| Message-ID | <COCYF-71A-3@gated-at.bofh.it> |
| In reply to | #101228 |
Hi Tim,
On Fri, Aug 20, 2021 at 05:29:54PM -0400, Timothy M Butterworth wrote:
> I have a new-be question, what is the point of merged-usr?
I put "debian merged-usr" into my favourite search engine and the
first result was:
https://wiki.debian.org/UsrMerge
Does this page and those linked from it answer your question
sufficiently as to what the point of the effort is?
The link near to the bottom:
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
is quite informative.
If you read those and it still isn't clear, it might be best to ask
about it on debian-user, as debian-devel would really be for Debian
Developers (who are mostly up to speed on this already to varying
degrees) to decide about *how* to do it, not the basics of *why* or if
it even *should* be done.
It has been the default for some time for new installs and the
tech-ctte already decided that it will be the only supported
configuration for the next release after bookworm. At this point
rehashing the whys of it would be repeating conversations had over
the last several years, so I feel like it's a user documentation
issue at this point if that's necessary.
Cheers,
Andy
[toc] | [prev] | [next] | [standalone]
| From | Timothy M Butterworth <timothy.m.butterworth@gmail.com> |
|---|---|
| Date | 2021-08-21 22:20 +0200 |
| Subject | Re: testing for rootfs vs. /usr reproducibility regressions |
| Message-ID | <COFDb-lL-5@gated-at.bofh.it> |
| In reply to | #101258 |
On 8/21/21, Andy Smith <andy@strugglers.net> wrote: > Hi Tim, > > On Fri, Aug 20, 2021 at 05:29:54PM -0400, Timothy M Butterworth wrote: >> I have a new-be question, what is the point of merged-usr? > > I put "debian merged-usr" into my favourite search engine and the > first result was: > > https://wiki.debian.org/UsrMerge > > Does this page and those linked from it answer your question > sufficiently as to what the point of the effort is? > > The link near to the bottom: > > http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge > > is quite informative. Thanks for the links, I have read them and I am all caught up now. This seems like something that Linux Standard Base LSB should have resolved regarding the installation directory. > If you read those and it still isn't clear, it might be best to ask > about it on debian-user, as debian-devel would really be for Debian > Developers (who are mostly up to speed on this already to varying > degrees) to decide about *how* to do it, not the basics of *why* or if > it even *should* be done. > > It has been the default for some time for new installs and the > tech-ctte already decided that it will be the only supported > configuration for the next release after bookworm. At this point > rehashing the whys of it would be repeating conversations had over > the last several years, so I feel like it's a user documentation > issue at this point if that's necessary. > > Cheers, > Andy > >
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2021-08-18 00:10 +0200 |
| Subject | Re: A summary of where I think we are on the technical side of the merged /usr discussion |
| Message-ID | <CNfrs-2Mf-19@gated-at.bofh.it> |
| In reply to | #101088 |
On Tue, 17 Aug 2021 at 15:08, Sam Hartman <hartmans@debian.org> wrote: > > >>>>> "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. Wouldn't a pre-depends solve the ordering problem in this case?
[toc] | [prev] | [next] | [standalone]
| From | Sam Hartman <hartmans@debian.org> |
|---|---|
| Date | 2021-08-18 07:00 +0200 |
| Subject | Re: A summary of where I think we are on the technical side of the merged /usr discussion |
| Message-ID | <CNlQe-6UW-1@gated-at.bofh.it> |
| In reply to | #101106 |
>>>>> "Luca" == Luca Boccassi <bluca@debian.org> writes:
Luca> Wouldn't a pre-depends solve the ordering problem in this
Luca> case?
No.
At least it's really hard to prove that it does, we have a bad track
record of getting it wrong, and if it were to work in a
specific instance it would depend on implementation details rather than
simply on guarantees made by the interfaces of dpkg and apt.
I'm not saying that something like that can't be part of a solution. If
it is, it will be because someone put in real effort into reasoning
about the correctness of the solution.
--Sam
[toc] | [prev] | [next] | [standalone]
Page 10 of 13 — ← Prev page 1 … 8 9 [10] 11 12 13 Next page →
Back to top | Article view | linux.debian.devel
csiph-web