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 4 of 13 — ← Prev page 1 2 3 [4] 5 6 … 13 Next page →
| From | Simon Richter <sjr@debian.org> |
|---|---|
| Date | 2021-07-28 16:40 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CFSSZ-35T-1@gated-at.bofh.it> |
| In reply to | #100883 |
[Multipart message — attachments visible in raw view] — view raw
Hi,
On 7/27/21 7:23 PM, Calum McConnell wrote:
> Of course, one could drop that to two years if you made the dpkg change a
> little bit more aggressive. Since we already have dpkg creating
> compatibility symlinks, why not have it also handle the file move? Simply
> treat all files shipped to /{bin,sbin,lib} as actually being shipped to
> /usr/{bin,sbin,lib}, and create symlinks accordingly. But that raises an
> important question.
This might be doable with diversions, but probably only for a closed set
of names. The Essential set is closed, but I'd suspect that there are
quite a few datacenter deployments (and deployment tools) that add
custom packages to debootstrap.
Simon
[toc] | [prev] | [next] | [standalone]
| From | Guillem Jover <guillem@debian.org> |
|---|---|
| Date | 2021-08-13 02:00 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CLsM9-6Go-3@gated-at.bofh.it> |
| In reply to | #100883 |
On Tue, 2021-07-27 at 13:23:46 -0400, Calum McConnell wrote: > > Of course, having to unnecessarily add more maintainer scripts to > > handle something that dpkg can do perfectly fine on its own > > TL;DR: merged-usr-via-symlink-farms cannot be done without changing dpkg, In my mind that's "false", but whatever yes… given that the reversion does not appear forthcoming, other new features might indeed be needed in case people do not want to be forced into this train wreck in slow motion. And as I mentioned on my first reply in this thread I'm prepared to devote any necessary volunteer time to implement such things in detriment of other Debian work if necessary. > and since the quote above seems to indicate you'd be willing to do that, > why not just change dpkg to support aliased dirs? I've mentioned this multiple times now, firstly because I think it would still be a broken layout. Secondly, because there are different types of dpkg features, some can be used right away, some others will still need at least two release cycles to be usable. The features that I think might be needed to be able to avoid being forced into using merged-usr-via-aliased-dirs, such as registering arbitrary files are of the former category. The features that would be needed to add support for merged-usr-via-aliased-dirs would be the latter. > Another way forward is to transition existing systems without merged-usr > to a merged-usr-via-symlink-farms. To accomplish this, we need the > ability to create symlinks in installations that are not usrmerge, but to > not create those links in installations that are. That requires either > maintainer scripts or a change to dpkg. You just criticized maintainer > scripts, so I would assume that they are not your favorite solution. Having to add maintainer script usage would be non-ideal, but would be better than being forced to use merged-usr-via-aliased-dirs. > Furthermore, others have pointed out that essential packages need to work > before maintainer scripts are executed. This behavior is codified in > policy: > > "Since dpkg will not prevent upgrading of other packages while an > > essential package is in an unconfigured state, all essential packages > > must supply all of their core functionality even when unconfigured". That's not what policy says. "unconfigured" does not mean that *maintainer scripts* have not been executed. > In other words, using maintainer scripts to create the symlinks that > enable the core functionality of these packages during configuration is a > no-go without a revision to policy and a change to dpkg (which might be > impossible). That means the symlinks would need to be included in the > package declaratively: but simply shipping them would break the existing > merged-usr installations. We've already established that un-merging and > then re-merging every installation isn't going to happen: so we'll need to > get the file references in place using a method that isn't shipping two > aliasing files and doesn't require maintainer scripts. This is based on an incorrect premise. In addition, as I've also said elsewhere bootstrapping is outside the realms of debian-policy anyway. > Simply modifying dpkg to automatically produce symlinks from /bin to > /usr/bin at unpack time is not enough either: dpkg isn't necessarily the > tool doing the unpacking, and so other tools would need to be modified, > each one of them checking for a merged-usr and then accounting for it if > needed. This solution is actually viable: it would lead to a working > system, and not break the essential guarantee. This is still based on an incorrect premise. And even though I'd find what you propose to be a major kludge, all bootstrappers I know of, always end up running dpkg over all .debs to do a proper installation of any possibly manually unpacked package. And not to mention that bootstrappers that support merged-usr-via-aliased-dirs have required implementing an explicit kludge for it. Regards, Guillem
[toc] | [prev] | [next] | [standalone]
| From | Marco d'Itri <md@Linux.IT> |
|---|---|
| Date | 2021-08-13 08:00 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CLyox-1V3-1@gated-at.bofh.it> |
| In reply to | #101006 |
[Multipart message — attachments visible in raw view] — view raw
Implementations with real /bin /sbin /lib* directories and symlink farms are not useful because they would negate the major benefits of merged-/usr, i.e. the ability of sharing and independently updating /usr. -- ciao, Marco
[toc] | [prev] | [next] | [standalone]
| From | Guillem Jover <guillem@debian.org> |
|---|---|
| Date | 2021-08-13 11:00 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CLBcK-3Nr-9@gated-at.bofh.it> |
| In reply to | #101009 |
On Fri, 2021-08-13 at 07:53:20 +0200, Marco d'Itri wrote: > Implementations with real /bin /sbin /lib* directories and symlink farms > are not useful because they would negate the major benefits of > merged-/usr, i.e. the ability of sharing and independently updating > /usr. Yes, that major benefit that is completely broken by design and unsupported anyway, because /etc and /var can also easily get out of sync. If you rely on this then you are on your own anyway… Also nothing prevents sharing /usr with symlink farms, iff all systems are in sync, which they must anyway. So that argument is pretty void of substance and founded on a base of unreliability… but what's new. Guillem
[toc] | [prev] | [next] | [standalone]
| From | Marco d'Itri <md@Linux.IT> |
|---|---|
| Date | 2021-08-13 17:30 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CLHi9-7Ug-1@gated-at.bofh.it> |
| In reply to | #101010 |
[Multipart message — attachments visible in raw view] — view raw
On Aug 13, Guillem Jover <guillem@debian.org> wrote: > Yes, that major benefit that is completely broken by design and > unsupported anyway, because /etc and /var can also easily get out > of sync. If you rely on this then you are on your own anyway… You say so, but it is a fact that in practice it works really well (within some constraints), and it can still be incrementally improved. -- ciao, Marco
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2021-08-13 11:20 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CLBw5-49m-3@gated-at.bofh.it> |
| In reply to | #101009 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, 2021-08-13 at 07:53 +0200, Marco d'Itri wrote: > Implementations with real /bin /sbin /lib* directories and symlink farms > are not useful because they would negate the major benefits of > merged-/usr, i.e. the ability of sharing and independently updating > /usr. > Indeed, it would be a completely pointless exercise. There's no benefit until you can safely ignore the split-usr legacy directories, which with this alternative scheme would never happen, and that's the whole point. As SUSE found out after wasting 10 years trying to implement this failed strategy, despite having tools and a build system that are light years ahead of what Debian has (and a stronger top-down governance model too, which doesn't leave much room for dissent), such package-by-package transition will never finish. It would be hard enough to get the thousands of non-debhelper source packages fixed, but even that leaves out all the third-party packages/repositories, a very large chunk of which doesn't even use dpkg-buildpackage (autogenerated .deb archives from CMake, Gradle, etc etc), let alone debhelper, and there's not a chance in hell to update them to include some custom postinst script for this purpose. Unless the intention is to deprecate allowing to change /etc/apt/sources.list and mandating that only hard-coded official Debian repositories can be used on Debian installations, of course, which would be, uh, interesting to see? -- Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | David Kalnischkies <david@kalnischkies.de> |
|---|---|
| Date | 2021-08-14 14:40 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CM17b-3Fo-1@gated-at.bofh.it> |
| In reply to | #101012 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, Aug 13, 2021 at 10:16:57AM +0100, Luca Boccassi wrote: > Unless the intention is to deprecate allowing to change /etc/apt/sources.list and mandating that only hard-coded official Debian repositories can be used on Debian installations, of course, which would be, uh, interesting to see? That is ironic given the current 'transition' plan is to have the release notes nudge all people who upgrade instead of reinstall their systems, chroots and what not to please do it for all of them by hand at a to be specified flag day someday between now and bookworm freeze – while a buster user might be able to do it now by hand, a repository admin has no such luxury as their packages have to continue to work until the flag day, so no dice embedding /usr/bin/grep, but after the flag day all dependencies could embed it breaking the unmerged build chroot still only having /bin/grep, so I hope we are picking a day on which every repository owner has some free time to do the flip… or well, deprecate them all as you suggest. As an APT dev I would approve. Not sure why you are singling out Debian as fine though, given we have the very same problem for our fleet of buildds and porterboxes, some DSA owned and some not. Thank goodness binary uploads by maintainers are a thing of the past never to be seen or even required for… oh, right… But yeah, upgrades. Minor problem. Nothing which can't be fixed with a good reinstall. To be clear: I couldn't care less about the if and how of /usr-merge. I do appreciate that some plans have a better upgrade experience though, not only as a user, but as dev as failed upgrades tend to be attributed to apt –– and I am a bit shocked we are fine with flag days nowadays. In the good old MultiArch days (that is a decade ago already!) a flag day wasn't even seriously considered an option desperate the costs. How times change… so it is okay now if I finally axe aptitude, right? :P (I am joking, I still think doing it this way was the right move – and the bigger cost is arch:all not being M-A:foreign by default anyhow) Best regards David Kalnischkies P.S.: I picked out only this line as I think most of the rest is more or less discussed to death already in other sub-threads and at times actually objectively wrong – like the amount of packages shipping something in /bin and co – so I don't feel like rehashing those. Not that I feel like wanting to discuss this point either, I just find it hideous to use a "what about upgrades?!?" hyperbole in this situation.
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2021-08-14 15:10 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CM1Ad-45L-1@gated-at.bofh.it> |
| In reply to | #101020 |
[Multipart message — attachments visible in raw view] — view raw
On Sat, 2021-08-14 at 14:33 +0200, David Kalnischkies wrote: > On Fri, Aug 13, 2021 at 10:16:57AM +0100, Luca Boccassi wrote: > > Unless the intention is to deprecate allowing to change > > /etc/apt/sources.list and mandating that only hard-coded official > > Debian repositories can be used on Debian installations, of course, > > which would be, uh, interesting to see? > > That is ironic given the current 'transition' plan is to have the > release notes nudge all people who upgrade instead of reinstall their > systems, chroots and what not to please do it for all of them by hand > at a to be specified flag day someday between now and bookworm > freeze – while a buster user might be able to do it now by hand, > a repository admin has no such luxury as their packages have to > continue > to work until the flag day, so no dice embedding /usr/bin/grep, but > after the flag day all dependencies could embed it breaking the > unmerged > build chroot still only having /bin/grep, so I hope we are picking a > day > on which every repository owner has some free time to do the flip… or > well, deprecate them all as you suggest. As an APT dev I would > approve. > > Not sure why you are singling out Debian as fine though, given we > have > the very same problem for our fleet of buildds and porterboxes, some > DSA > owned and some not. Thank goodness binary uploads by maintainers are > a thing of the past never to be seen or even required for… oh, right… > > But yeah, upgrades. Minor problem. > Nothing which can't be fixed with a good reinstall. > > > To be clear: I couldn't care less about the if and how of /usr-merge. > I do appreciate that some plans have a better upgrade experience > though, > not only as a user, but as dev as failed upgrades tend to be > attributed > to apt –– and I am a bit shocked we are fine with flag days nowadays. > In the good old MultiArch days (that is a decade ago already!) a flag > day wasn't even seriously considered an option desperate the costs. > How > times change… so it is okay now if I finally axe aptitude, right? :P > (I am joking, I still think doing it this way was the right move – > and > the bigger cost is arch:all not being M-A:foreign by default anyhow) > > > Best regards > > David Kalnischkies > > P.S.: I picked out only this line as I think most of the rest is more > or less discussed to death already in other sub-threads and at times > actually objectively wrong – like the amount of packages shipping > something in /bin and co – so I don't feel like rehashing those. Not > that I feel like wanting to discuss this point either, I just find it > hideous to use a "what about upgrades?!?" hyperbole in this > situation. Were upgrades impossible in Ubuntu when it switched and were manual reinstallation mandatory for the entire user base, chroots, whatnot? No. Then why should it be the case for Debian if we do the exact same thing with the exact same tools? -- Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | David Kalnischkies <david@kalnischkies.de> |
|---|---|
| Date | 2021-08-14 16:00 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CM2mB-4lb-1@gated-at.bofh.it> |
| In reply to | #101021 |
[Multipart message — attachments visible in raw view] — view raw
On Sat, Aug 14, 2021 at 02:08:33PM +0100, Luca Boccassi wrote: > Were upgrades impossible in Ubuntu when it switched and were manual > reinstallation mandatory for the entire user base, chroots, whatnot? > No. Then why should it be the case for Debian if we do the exact same > thing with the exact same tools? Oh, I didn't know we had a release upgrade tool orchestrating the upgrade like they do. You should tell the release team, I think they are still looking for a bulletproof solution to upgrade ssh early among other things. And I am pretty sure the unmerged chroots are an open question for them still as nobody is running the upgrader in there of course. See also https://bugs.debian.org/985957. Best regards David Kalnischkies
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2021-08-14 15:30 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CM1TA-4bK-3@gated-at.bofh.it> |
| In reply to | #101020 |
On Sat, 14 Aug 2021 at 14:33:44 +0200, David Kalnischkies wrote:
> the current 'transition' plan is to have the
> release notes nudge all people who upgrade instead of reinstall their
> systems, chroots and what not to please do it for all of them by hand
> at a to be specified flag day someday between now and bookworm
> freeze
That is certainly not my plan. It might be someone's plan, but it is not
one that I would support.
I think the earliest flag day that would be possible (for requiring merged
/usr, or for completely undoing merged /usr, or for any similarly "big"
transitional path) is the bookworm release date. We specifically don't
support skipping a release, so the fastest possible timeline for an
archive-wide transition goes something like this:
1. during bookworm development: interested people make the transition as
robust and graceful as possible; package maintainers must make their
packages compatible with the transition (if they have not already) but
must not assume that the transition has already taken place
2. bookworm release: systems must transition at or before the upgrade to
bookworm (bullseye systems are not required to transition until/unless
they are upgraded)
3. during bookworm+1 development (testing/unstable post bookworm):
package maintainers may assume the transition has taken place
smcv
[toc] | [prev] | [next] | [standalone]
| From | David Kalnischkies <david@kalnischkies.de> |
|---|---|
| Date | 2021-08-14 17:00 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CM3iF-5c9-1@gated-at.bofh.it> |
| In reply to | #101022 |
[Multipart message — attachments visible in raw view] — view raw
On Sat, Aug 14, 2021 at 02:26:29PM +0100, Simon McVittie wrote: > On Sat, 14 Aug 2021 at 14:33:44 +0200, David Kalnischkies wrote: > > the current 'transition' plan is to have the > > release notes nudge all people who upgrade instead of reinstall their > > systems, chroots and what not to please do it for all of them by hand > > at a to be specified flag day someday between now and bookworm > > freeze > > I think the earliest flag day that would be possible (for requiring merged > /usr, or for completely undoing merged /usr, or for any similarly "big" > transitional path) is the bookworm release date. We specifically don't That would be nice, but isn't what the CTTE ruled as the implementation of the resolution (= no longer supporting non-merged-usr layout) is delayed until after the release of bullseye. That is also what the bullseye release notes say, too. Wouldn't it be kinda strange to have the chroots building the packages for the first bookworm release using a layout which isn't supported by bookworm itself… and wouldn't it be even worse if we change from the quasi-bookworm unmerged unstable chroots to the bookworm merged chroots [as unmerged isn't supported for them] for building the packages of the first point release? That is why I said freeze as I kinda doubt the release team would like to have a big change for bullseye after the freeze… > 2. bookworm release: systems must transition at or before the upgrade to > bookworm (bullseye systems are not required to transition until/unless > they are upgraded) The "at" in this sentence means that all bookworm packages must support unmerged as you can't guarantee that the transition happens before¹ and forces bookworm chroots to be unmerged as well as the packages built in them will be used to upgrade from bullseye as we don't do →.0 → .1 → … upgrades. That is of course in direct contraction to not supporting it anymore. Best regards David Kalnischkies ¹ well, you could by having $magic implemented with the essential set and shipped in something like base-files (= installed everywhere) to pre-depend on it from quite literally every package in existence. [shouldn't be a new package as release notes traditionally advice to run an upgrade without installing new packages first] Kinda doubt that would work in practice…
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2021-08-15 01:20 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CMb6x-1MD-5@gated-at.bofh.it> |
| In reply to | #101024 |
On Sat, 14 Aug 2021 at 16:59:24 +0200, David Kalnischkies wrote:
> Wouldn't it be kinda strange to have the chroots building the packages
> for the first bookworm release using a layout which isn't supported by
> bookworm itself…
Yes, it's a little strange, but that's what happens when we don't want
a mid-release-cycle flag day: we have to sequence things somehow. For best
robustness for users of non-merged-/usr, build chroots should likely
be one of the last things to become merged-/usr, and build chroots for
suites like buster and bullseye that support non-merged-/usr should stay
non-merged-/usr until those suites are completely discontinued.
Note that packages built in a non-merged-/usr chroot work fine on a
merged-/usr system, as long as they don't contain both /foo and /usr/foo
(which is more likely to be a fact about the package than a fact about
the chroot, and would already be considered RC since buster).
The failure mode we have sometimes seen is packages that were built in
a merged-/usr chroot not working on a non-merged-/usr system, although
that's detected by the reproducible-builds infrastructure and is already
considered to be a bug since buster (AIUI it's considered a non-RC bug
in buster and bullseye, as a result of things like #914897 mitigating it).
The reason for this choice of sequencing is that we *do* care about
existing installations (specifically, those that were installed before
buster or with non-default debootstrap options, and have been upgraded
since then without installing usrmerge or carrying out the /usr merge
some other way).
> > 2. bookworm release: systems must transition at or before the upgrade to
> > bookworm (bullseye systems are not required to transition until/unless
> > they are upgraded)
>
> The "at" in this sentence means that all bookworm packages must support
> unmerged
Yes, that's what I said: package maintainers must not assume/require
the new layout until step 3, which is when they start uploading to
unstable post-bookworm. If package maintainers want to be able to
assume/require merged-/usr sooner, then they are going to be disappointed,
but that's part of the price we pay for having upgrades that work.
In the timeline I outlined, the target layout (merged /usr, according
to the technical committee resolution) is the only thing officially
supported *for bookworm as a whole* - but every[1] package in bookworm,
individually, must support both the target layout and the "other" layout
(the same as they did in bullseye), because partial upgrades are a thing.
I think this works both ways round: if, instead, we wanted to "rewind"
to the situation of a few years ago where merged /usr was not possible,
by passing through a release-time flag day after which all supported
systems must be unmerged-/usr, then the soonest that package maintainers
could assume/require an unmerged /usr (and therefore start to ship both
/foo and /usr/foo) would be the day after the bookworm release.
smcv
[1] Depending on how you look at it, packages like usrmerge that are part
of implementing the transition might be considered to be an exception
to this - although they do get installed on a system that does not
have the target layout, in order to turn it into a system that does,
so you could also say that they do (and must!) support the other layout.
[toc] | [prev] | [next] | [standalone]
| From | David Kalnischkies <david@kalnischkies.de> |
|---|---|
| Date | 2021-08-15 12:00 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CMl5T-8g6-5@gated-at.bofh.it> |
| In reply to | #101025 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, Aug 15, 2021 at 12:16:39AM +0100, Simon McVittie wrote: > On Sat, 14 Aug 2021 at 16:59:24 +0200, David Kalnischkies wrote: > > Wouldn't it be kinda strange to have the chroots building the packages > > for the first bookworm release using a layout which isn't supported by > > bookworm itself… > > Yes, it's a little strange, but that's what happens when we don't want > a mid-release-cycle flag day: we have to sequence things somehow. For best > robustness for users of non-merged-/usr, build chroots should likely > be one of the last things to become merged-/usr, and build chroots for > suites like buster and bullseye that support non-merged-/usr should stay > non-merged-/usr until those suites are completely discontinued. You snipped both times the [for me] logical consequence that all bookworm build chroots are kept in a [then unsupported] unmerged state as "one of the last things" aka until bookworm is discontinued, so that they are building the packages who do will encounter unmerged systems in the upgrade as a user can perfectly well upgrade from bullseye to the ninth point-release of bookworm months after the initial release of bookworm. > The failure mode we have sometimes seen is packages that were built in > a merged-/usr chroot not working on a non-merged-/usr system, although > that's detected by the reproducible-builds infrastructure and is already > considered to be a bug since buster (AIUI it's considered a non-RC bug > in buster and bullseye, as a result of things like #914897 mitigating it). So, your reasoning is that tooling will help us ensure that packages built on merged systems work on non-merged systems? Good! No flag day required then, we can just naturally upgrade all systems as they encounter the $magic and have new buildd chroots bootstrapped now merged instead of enforcing them being unmerged still (modulo whatever the implementation itself might be of course). I am happy as that wasn't clearly said before and current practice and previous discussions suggested the opposite¹ (at least for me). Thanks & good luck! If on the other hand you do still anticipate problems with packages built on merged systems for non-merged systems requiring a flag day I don't understand why it makes sense to have that flag day be bookworm release day² as that brings the anticipated problems to the bullseye→bookworm upgrades with the first point release (with the first package with a stable or security update to be more exact³). Best regards David Kalnischkies ¹ e.g. Marga is saying in #978636 msg#153 that migration from unmerged is not required to be implemented for bookworm [and therefore effectively at all] for unmerged to be unsupported in bookworm. ² Leaving aside how we would even technically implement a flag day so that unstable (building bookworm packages until release day) stays unmerged until magically merging on release day while testing merges on install (before that) for… testing? ³ I understand that only a subset actually breaks for non-merged if build on merged, but I prefer to assume that the first one is such a package to be prepared rather than pray to deity (pun intended) and hope for the best.
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2021-08-15 19:00 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CMrEm-46h-3@gated-at.bofh.it> |
| In reply to | #101031 |
On Sun, 15 Aug 2021 at 11:52:21 +0200, David Kalnischkies wrote:
> You snipped both times the [for me] logical consequence that all
> bookworm build chroots are kept in a [then unsupported] unmerged state
> as "one of the last things" aka until bookworm is discontinued,
> so that they are building the packages who do will encounter unmerged
> systems in the upgrade as a user can perfectly well upgrade from bullseye
> to the ninth point-release of bookworm months after the initial release
> of bookworm.
Hmm, that's a good point. That hadn't occurred to me, and you're right,
it's not ideal.
One way out of this would be to say that it is a RC bug for packages
in bookworm to have different contents when built in equivalent
merged-/usr and unmerged-/usr chroots/containers (a higher severity
than is currently applied, which I think would be a "normal" or "minor"
bug for violating the Policy "should" rule that packages should be
reproducible). That would mean we can validly merge /usr in buildd
chroots, and if any package ends up broken in that situation, it's up
to the package maintainer (or our usual NMU/bug-squashing processes) to
fix it. According to https://isdebianreproducibleyet.com/, fewer than 5%
of Debian packages are non-reproducible for any of the reasons we test,
including but not limited to whether the buildd chroot was merged-/usr
(the reproducible-builds infrastructure uses unmerged-/usr for "build 1"
and then installs usrmerge before "build 2"), so that's an upper bound
for the number of packages affected.
Another way out of this would be to say that merged /usr is the only
state supported for bookworm, with the exception that chroots/containers
that will never be upgraded beyond bookworm (+ updates + security)
are allowed to remain unmerged-/usr (and we'd probably want to say
that adding bookworm-backports to an unmerged-/usr chroot/container
is officially not supported either). That would mean the unmerged
buildd chroots are (just about) in a supported state, while still
letting maintainers assume/require merged-/usr post-bookworm, because
by definition the chroots/containers where that exception applies are
never going to reach a post-bookworm state (they'll be discarded when
they are no longer used, instead).
> So, your reasoning is that tooling will help us ensure that packages
> built on merged systems work on non-merged systems? Good!
This is basically another phrasing of the first option I described above,
I think.
> No flag day
> required then, we can just naturally upgrade all systems as they
> encounter the $magic and have new buildd chroots bootstrapped now
> merged instead of enforcing them being unmerged still
> (modulo whatever the implementation itself might be of course).
If we are going to reach a state where package maintainers can
assume/require merged-/usr (for example being able to drop code paths that
only needed to exist because unmerged-/usr is supported), then we need
some point in the release/upgrade process where that requirement becomes
official - and IMO that point in time might as well be a particular Debian
release, because that would be consistent with the rules we normally
use to drop other code that was historically required but is no longer
relevant, like Breaks/Replaces or workarounds in maintainer scripts.
It isn't a flag day in the sense that the whole world needs to switch at
the same time, more like a support cutoff (like the way we discontinue
security support as a stable suite gets older, first for selected
problematic packages and architectures and then for the entire suite).
That point doesn't necessarily have to be bookworm r0, but I think
bookworm r0 is the earliest it can be. If we're scared of commitment,
we could say that merged-/usr is the only supported layout for bookworm,
but not pull the trigger on allowing unmerged-/usr code paths to be
removed until bookworm+1 - but that would leave those code paths untested,
and we know that untested code usually doesn't work.
Strictly speaking, the cutoff in the timeline I proposed isn't bookworm r0,
it's the first time you update from testing/unstable *after* bookworm r0.
> ¹ e.g. Marga is saying in #978636 msg#153 that migration from unmerged
> is not required to be implemented for bookworm [and therefore
> effectively at all] for unmerged to be unsupported in bookworm.
Well, we have the usrmerge package, so an implementation exists. It isn't
perfect, and I hope that between now and the bookworm freeze, we can get a
better migration path than `apt install usrmerge` as currently implemented
(either in a new revision of the usrmerge package, or elsewhere); but it
mostly works in practice.
Doing what usrmerge does from a maintainer script is pretty scary from a
robustness/interruptability point of view. Without my Technical Committee
hat on, one route that I think should be considered is deferring the
migration until the next boot and doing it from the initramfs, so that
nothing else will be concurrently writing to the root filesystem. In terms
of the mechanics of upgrading to bookworm, this would mean that all the
bookworm packages get installed into an unmerged-/usr system running the
bullseye kernel, and then the next reboot switches to a merged-/usr system
running the bookworm kernel.
The reasons Marga is being careful not to mandate any specific
implementation in that message are that detailed design is specifically
outside the Technical Committee's role, and that the TC doesn't want to
constrain the implementation: whatever implementation plans people come
up with, we would like the best one to be used, and we certainly don't
want a TC resolution that preemptively forbids the best implementation
because we hadn't thought of it at the time.
> ³ I understand that only a subset actually breaks for non-merged if
> build on merged, but I prefer to assume that the first one is such
> a package to be prepared rather than pray to deity (pun intended) and
> hope for the best.
It certainly wouldn't be ideal for the security team (or package
maintainers) to have to fix package reproducibility before a security
update can be released, but I think we already have situations where
the security team have to fix a FTBFS, test failure, Lintian autoreject
or other non-security-related RC bug before a security update can be
released. If we say that merged-/usr vs. unmerged-/usr non-reproducibility
is RC, then it's "just" another class of RC bug that might need fixing
before the package can be updated successfully.
smcv
[toc] | [prev] | [next] | [standalone]
| From | Marco d'Itri <md@Linux.IT> |
|---|---|
| Date | 2021-08-16 01:10 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CMxqp-7UY-3@gated-at.bofh.it> |
| In reply to | #101034 |
[Multipart message — attachments visible in raw view] — view raw
On Aug 15, Simon McVittie <smcv@debian.org> wrote: > Doing what usrmerge does from a maintainer script is pretty scary from a > robustness/interruptability point of view. Without my Technical Committee > hat on, one route that I think should be considered is deferring the > migration until the next boot and doing it from the initramfs, so that > nothing else will be concurrently writing to the root filesystem. In terms I have tried that in the initramfs branch of the usrmerge repository but I was never able to actually make it work, probably because I do not know initramfs-tools well enough. And I have not been motivated to spend any more time on it since the issue with systemd's sandboxing has been solved in other ways. But I had been thinking a lot about how usrmerge works when I originally wrote it and I do not think that "something else concurrently writing to the root filesystem" is an actual concern because only the package manager is supposed to modify /bin, /sbin and /lib* and at that time it is intrinsecally locked by usrmerge being installed. And just to be sure, before the old directories are deleted the program checks that they only contain symlinks. There is a genuine race while the symlink farms directories are being replaced by the final symlink and I have described a possible race-free solution, but I do not think that the added complexity would be justified because the worst thing that could happen is that a program being run at that exact time will fail to start. BTW: the usrmerge package has been in the archive for 6 years now. -- ciao, Marco
[toc] | [prev] | [next] | [standalone]
| From | David Kalnischkies <david@kalnischkies.de> |
|---|---|
| Date | 2021-08-16 11:50 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CMHpM-5So-11@gated-at.bofh.it> |
| In reply to | #101036 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, Aug 16, 2021 at 12:59:31AM +0200, Marco d'Itri wrote: > BTW: the usrmerge package has been in the archive for 6 years now. /usr/bin/apt exists for 8 years now and the release notes advice using it in every section. So, how come people are still typing apt-get interactively to upgrade? Is perhaps pure existence not enough, do I need to provide an upgrade path as simple as possible as well? At least apt is installed on every system in existence automatically, you don't have to go out of your way to install it manually, so that transition seems painless and even removes 4 keystrokes in comparison! What is your transition plan from unmerged to merged? That is the simple question of this sub-thread and so far Simon told me how he plans it. As you have worked on yours for years now I would be happy if you could point to/tell me yours as I could only find "you have to do it manually" so far. Surely you came up with something a lot better after all those years. Best regards David Kalnischkies P.S.: For the avoidance of doubt: apt-get is of course going nowhere, but that cuts both ways: It isn't changing as your fingers hate change – so e.g. no new interactive questions fingers aren't trained to answer…
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2021-08-16 14:40 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CMK4h-7vX-15@gated-at.bofh.it> |
| In reply to | #101046 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, 2021-08-16 at 11:47 +0200, David Kalnischkies wrote: > On Mon, Aug 16, 2021 at 12:59:31AM +0200, Marco d'Itri wrote: > > BTW: the usrmerge package has been in the archive for 6 years now. > > /usr/bin/apt exists for 8 years now and the release notes advice using > it in every section. So, how come people are still typing apt-get > interactively to upgrade? > > Is perhaps pure existence not enough, do I need to provide an upgrade > path as simple as possible as well? > > At least apt is installed on every system in existence automatically, > you don't have to go out of your way to install it manually, so that > transition seems painless and even removes 4 keystrokes in comparison! > > > What is your transition plan from unmerged to merged? > > > That is the simple question of this sub-thread and so far Simon told me > how he plans it. As you have worked on yours for years now I would be > happy if you could point to/tell me yours as I could only find "you have > to do it manually" so far. Surely you came up with something a lot > better after all those years. > > > Best regards > > David Kalnischkies > > P.S.: For the avoidance of doubt: apt-get is of course going nowhere, > but that cuts both ways: It isn't changing as your fingers hate change – > so e.g. no new interactive questions fingers aren't trained to answer… Why would it have to be manual? Ubuntu made the usrmerge package recommended by ubuntu-minimal in 21.04, which means all installations that were not already switched (ie, installations older than 19.04) were converted by default, unless manual action was taken to avoid it. IIRC the plan is to move from recommends to depends by next year, to ensure any last remaining manual opt-out is moved along as well. https://packages.ubuntu.com/hirsute/ubuntu-minimal https://bugs.launchpad.net/ubuntu/+source/usrmerge/+bug/1906671 -- Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Marco d'Itri <md@Linux.IT> |
|---|---|
| Date | 2021-08-16 15:20 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CMKH0-7YL-9@gated-at.bofh.it> |
| In reply to | #101046 |
[Multipart message — attachments visible in raw view] — view raw
On Aug 16, David Kalnischkies <david@kalnischkies.de> wrote: > Is perhaps pure existence not enough, do I need to provide an upgrade > path as simple as possible as well? If you have specific ideas about how the upgrade path could be improved then I am interested in hearing them. I think that it is hard to beat "apt install usrmerge", but it could still be improved by having some essential package depend on "usrmerged | usrmerge" (with usrmerged being an empty transitional package which ensures that the system has a merged-/usr). -- ciao, Marco
[toc] | [prev] | [next] | [standalone]
| From | David Kalnischkies <david@kalnischkies.de> |
|---|---|
| Date | 2021-08-17 12:10 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CN4cF-3pJ-1@gated-at.bofh.it> |
| In reply to | #101051 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, Aug 16, 2021 at 03:13:48PM +0200, Marco d'Itri wrote: > On Aug 16, David Kalnischkies <david@kalnischkies.de> wrote: > > Is perhaps pure existence not enough, do I need to provide an upgrade > > path as simple as possible as well? > If you have specific ideas about how the upgrade path could be improved > then I am interested in hearing them. > I think that it is hard to beat "apt install usrmerge", but it could I see… we have a drastically different opinion on what a simple upgrade path is then; but never mind me labeling it "couldn't be much worse" as long as we agree it could … > still be improved by having some essential package depend on > "usrmerged | usrmerge" (with usrmerged being an empty transitional > package which ensures that the system has a merged-/usr). I was discussing this here with Simon already as this needs either: a) a guarantee that packages built on merged systems work on unmerged OR b) supporting unmerged in bookworm so buildds and co can be run unmerged Beside the promise that all packages in bookworm support running on merged and unmerged as you can't really guarantee at which point the conversion happens, but that at least is easy as it should be the status quo (I know there are people who disagree on that already in other branches of the thread, but I am not here to shave that yak). a) couldn't be promised so far leading to chroots being unmerged and b) is at odds with the CTTE decision and a bit awkward as it requires manual intervention to keep build machines and co unmerged, but that is at least a much smaller "manual intervention required" set than doing nothing at all by default. [Of course, the or-group itself would need to be reversed, but I guess that was a typo; and ideally usrmerge would be lighter – but that is already discussed in a bug – as it is pseudo-essential and installed for everyone] Best regards David Kalnischkies
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2021-08-17 12:30 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CN4w1-3yt-5@gated-at.bofh.it> |
| In reply to | #101081 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, 2021-08-17 at 12:07 +0200, David Kalnischkies wrote: > On Mon, Aug 16, 2021 at 03:13:48PM +0200, Marco d'Itri wrote: > > On Aug 16, David Kalnischkies <david@kalnischkies.de> wrote: > > > Is perhaps pure existence not enough, do I need to provide an upgrade > > > path as simple as possible as well? > > If you have specific ideas about how the upgrade path could be improved > > then I am interested in hearing them. > > I think that it is hard to beat "apt install usrmerge", but it could > > I see… we have a drastically different opinion on what a simple upgrade > path is then; but never mind me labeling it "couldn't be much worse" as > long as we agree it could … > > > still be improved by having some essential package depend on > > "usrmerged | usrmerge" (with usrmerged being an empty transitional > > package which ensures that the system has a merged-/usr). > > I was discussing this here with Simon already as this needs either: > a) a guarantee that packages built on merged systems work on unmerged OR > b) supporting unmerged in bookworm so buildds and co can be run unmerged > > Beside the promise that all packages in bookworm support running on > merged and unmerged as you can't really guarantee at which point the > conversion happens, but that at least is easy as it should be the > status quo (I know there are people who disagree on that already in > other branches of the thread, but I am not here to shave that yak). > > > a) couldn't be promised so far leading to chroots being unmerged and > b) is at odds with the CTTE decision and a bit awkward as it requires > manual intervention to keep build machines and co unmerged, but that is > at least a much smaller "manual intervention required" set than doing > nothing at all by default. > > > [Of course, the or-group itself would need to be reversed, but I guess > that was a typo; and ideally usrmerge would be lighter – but that is > already discussed in a bug – as it is pseudo-essential and installed > for everyone] > > > Best regards > > David Kalnischkies If src:usrmerge is made transitively-essential, from that point onward it wouldn't matter if a package is no longer compatible with the legacy split-usr setup, no? Because in order to apt ugprade and get that, you'll also get usrmerge and the conversion will be done, right? Or am I missing something? -- Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
Page 4 of 13 — ← Prev page 1 2 3 [4] 5 6 … 13 Next page →
Back to top | Article view | linux.debian.devel
csiph-web