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 11 of 13 — ← Prev page 1 … 9 10 [11] 12 13 Next page →
| From | Tim Woodall <debiandevel@woodall.me.uk> |
|---|---|
| Date | 2021-08-18 18:20 +0200 |
| Subject | Re: A summary of where I think we are on the technical side of the merged /usr discussion |
| Message-ID | <CNwsh-5Bo-11@gated-at.bofh.it> |
| In reply to | #101116 |
On Tue, 17 Aug 2021, Sam Hartman wrote: >>>>>> "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 > > I'm not proposing this as a solution, or even a part solution, but I have a script that generates a set of Depends: between essential packages that (I believe) guarantees that they will install and will (I hope) "fail" if no such solution is possible. (I don't use this any more, I'm using "essential-on-a-diet" which I manage manually but it's something I have which others might be able to adapt into something more useful) http://www.woodall.me.uk/debian/find_depends.sh
[toc] | [prev] | [next] | [standalone]
| From | Tim Woodall <debiandevel@woodall.me.uk> |
|---|---|
| Date | 2021-08-18 09:50 +0200 |
| Subject | Changing how you do things: Was Re: merged /usr |
| Message-ID | <CNouJ-ro-3@gated-at.bofh.it> |
| In reply to | #101046 |
On Mon, 16 Aug 2021, David Kalnischkies wrote:
> /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?
>
> 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?
>
One of the problems is that the "upgrade" path is never easy for
experienced users. One thing that could help would be something like:
-o APT::NewCommand=yes option (or something like that) that to
apt-get/apt-cache which took the command line and told you exactly what
apt incantation you need to achieve exactly the same results.
I'm looking at a script of mine that can take around 20 minutes to
complete and has 9 apt-get incantations.
I have things like;
DEBIAN_FRONTEND=noninteractive apt-get -q -y install \
-o APT::Architecture=${ARCH} -o APT::Install-Recommends=false \
-o APT::Get::Simulate=true -o RootDir=image apt | tee apt-simulate.log
and then the rest of the script depends on the contents of
apt-simulate.log
I could update it to apt - but the script currently supports four
releases across four architectures. So even if the changes are all
"no-brainers" it's going to take an overnight run to confirm that
everything still works. And if, inevitably, there are tweaks required,
then it becomes a long drawn out red queen's race. This is a personal
project "for fun" and "because I can" and time taken updating this
script to apt "because the documentation says I should" is time I cannot
spend on more interesting stuff (from my PoV)
Even upgrading from buster to bullseye is potentially fraught - perhaps
apt-simulate.log will change. One of my projects over the last few years
has been to slowly change so that everything now runs in VMs and each VM
should only do one thing - that way upgrades can be managed and breaking
changes can be handled one by one. I think I'm finally in position to
consider adopting systemd. I had dozens of init scripts, udev rules etc,
some of which have barely been touched for a couple of decades that will
all need to be rewritten, some of which I need to "just work" (and some
of which possibly don't do anything any more but I've never noticed...)
The script I commented on above is part of my project to ensure that any
and all changes to the default debian install are done via packages. I'm
not there yet but, for example, I can now rebuild a VM from scratch and
then diff things like /etc to check that I've captured everything in a
package. I started this project two years ago today (coincidence!) and
last week I finally got into the state where I can do that for
everything I use at home. I still have changes I need to package, and I
still have VMs that are running too many unrelated services, but I'm
slowly getting there.
Ironically, the /usr-merge is almost a "no brainer" for me. It's only
after reading the comments here that I realize it's actually a difficult
problem to solve cleanly because it's so easy for me to deal with. I can
see why Guillem is frustrated.
[toc] | [prev] | [next] | [standalone]
| From | David Kalnischkies <david@kalnischkies.de> |
|---|---|
| Date | 2021-08-18 15:00 +0200 |
| Subject | Re: Changing how you do things: Was Re: merged /usr |
| Message-ID | <CNtkL-3zC-9@gated-at.bofh.it> |
| In reply to | #101117 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, Aug 18, 2021 at 08:33:01AM +0100, Tim Woodall wrote: > […] and time taken updating this > script to apt "because the documentation says I should" is time I cannot > spend on more interesting stuff (from my PoV) For the record: The apt documentation says the opposite. /usr/bin/apt is even annoyingly insistent on not being run inside a script or even its output being redirected to a file. I was talking (in half-jest) about interactive usage – aka your fingers typing all commands manually into a terminal one by one. That is also what the release notes are primarily concerned with. We know perfectly well that apt-get is used all over the place in the strangest of usecases by scripts potentially nobody knows howto or has the time to maintain. As a result apt-get (and the rest of the apt-* family) aren't changing their behaviour much if at all from release to release, which results in some behaviour being suboptimal if not downright bad, but the default none the less as it would be too costly to change the default (a fun example of a minor change having unexpected consequences is breaking Debian CD building with apt-cache show #712435). apt on the other hand can be changed "at will" as we expect a being on the other side of the terminal who is able to react to changes like a new question asking if this potentially security relevant change is okay & expected. Scripts can't usually react, with them we can only communicate via failing the execution if we deem the risk high enough to do so to hopefully summon a being capable of reasoning to look into the failing of the script. btw: `apt-config dump Binary::apt` will tell you (most) of the config options apt changes compared to the 'old' defaults in apt-get and co. There aren't that many (so far). Best regards David Kalnischkies
[toc] | [prev] | [next] | [standalone]
| From | David Kalnischkies <david@kalnischkies.de> |
|---|---|
| Date | 2021-08-16 11:50 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CMHpL-5So-7@gated-at.bofh.it> |
| In reply to | #101034 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, Aug 15, 2021 at 05:52:06PM +0100, Simon McVittie wrote: > On Sun, 15 Aug 2021 at 11:52:21 +0200, David Kalnischkies wrote: > 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). > > 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. Yes. And for the avoidance of doubt: If that is part of the plan I am happy as it is one step closer to upgrade sanity. > > 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. Sure, such a flag day for stuff effecting bookworm+1 is fine, my concern was with the effect the flag day has on bookworm itself, by saying unmerged is not support in bookworm while potentially still requiring such systems to continue to exist [= not option 1] and/or having no facility to upgrade them automatically to stay supported. If it hasn't you can do whatever as far as I am concerned, but that isn't what was said until now (and what you repeat in the next paragraph…). So, yes, your strict speaking: > 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. Yeah, well, that is exactly how I have read and understood the discussion so far which means everyone has to run it manually to upgrade every system, container, chroot, … not recently freshly installed … *urgh* That isn't an upgrade path for me and I can't stand others claiming it would be, which triggered this sub-thread to begin with if you remember… > Doing what usrmerge does from a maintainer script is pretty scary from a > robustness/interruptability point of view. Without my Technical Committee "Upgrades are like sausages, it is better not to see them being made." -- Otto von Bismarck (except he said Laws of course) I know it is a major discussion point in this megathread, but that isn't my field of interest, so I feel not qualified to comment on technical details of the implementation of any plan of /usr-merge itself and happily leave that to experts. All I am asking for is a way that ensures that 99% of systems currently supported as buster/bullseye can be upgraded to bookworm and later to bookworm+1 and remain supported without manual intervention. That isn't too much to ask, is it? :P Heck, if we figured out that this isn't possible with dependencies and/or maintainer script we could perhaps even implement something in apt to ensure invariants like "to be able to upgrade to X, you have to install Y first (here, let me do that for you automatically)". Maybe we should ask an apt maintainer…¹ 😉 But that pre-requires that a plan is made by someone who actually knows how its supposed to work… Julian e.g. proposed a silly one[0] in freeze, but that it is of course not workable to print warnings if huge parts of systems apt runs on (e.g. buildd chroots) have to ignore that warning for years (, can't be automated due to this either) and is as usual 2 years too late. (for at least 6 years now as Marco pointed out. I will let the interested reader do the math on that one…) [0] https://salsa.debian.org/apt-team/apt/-/merge_requests/162 ¹ It is early in the cycle, I can still dream of big features we always want to have after the fact, but never find the time and reason before. Maybe this time… > The reasons Marga is being careful not to mandate any specific > implementation […] I get that, but I am a bit unhappy that carrots (= you don't have to support unmerged anymore) are given out without requiring that there is a (not entirely manual) upgrade path for the to-be-unsupported first. Ideally, that path already exists if you change the default and don't intended to keep the old default working forever but that ship sailed even earlier… Every time an upgrade problem is reported against apt I am telling the maintainer that I can only help them so far as I am not a domain expert of the packages involved and they are ultimately responsible to ensure the upgrade works to be part of the release (= carrot), not the apt maintainers, as it would never scale if the release team allowed them to be part of the release anyhow and left it for others to figure out how to make the upgrades work somehow (it is bad enough we sorta do for key packages as that gives us nightmares like libgcc_s did this time). So how big must a change be that we effectively make upgrades an entirely optional afterthought like Debian did here? Best regards David Kalnischkies
[toc] | [prev] | [next] | [standalone]
| From | Holger Levsen <holger@layer-acht.org> |
|---|---|
| Date | 2021-08-17 11:50 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CN3Tj-32Q-9@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: > 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). FWIW i'm preparing a commit right now which will change the reproducible-builds infrastructure in so far as: - bullseye will not be tested anymore for differences of building with or without the usrmerge package installed (just like stretch and buster were and are not). - bookworn and unstable will be tested for differences of building with or without the usrmerge package installed. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ :wq
[toc] | [prev] | [next] | [standalone]
| From | Vagrant Cascadian <vagrant@reproducible-builds.org> |
|---|---|
| Date | 2021-08-17 18:30 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CNa8p-7sB-11@gated-at.bofh.it> |
| In reply to | #101079 |
[Multipart message — attachments visible in raw view] — view raw
On 2021-08-17, Holger Levsen wrote: > On Sun, Aug 15, 2021 at 12:16:39AM +0100, Simon McVittie wrote: >> 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). > > FWIW i'm preparing a commit right now which will change the reproducible-builds > infrastructure in so far as: > > - bullseye will not be tested anymore for differences of building with or > without the usrmerge package installed (just like stretch and buster were > and are not). > - bookworn and unstable will be tested for differences of building with or > without the usrmerge package installed. Given: TC decision on "Merged /usr" https://bugs.debian.org/914897 The short of it, as I read it, is that non-usrmerge systems will be unsupported for bookworm, or did I misread that? I would almost think it makes more sense to *not* test usrmerge for bookworm, but continue to test it for bullseye and unstable (and experimental) in the reproducible builds infrastructure. This is my quick rationale for why I think that: * bullseye has been doing usrmerge variations for it's entire development cycle, it seems odd to change now. * Keeping unstable/sid with usrmerge variations is good for QA, as it does occasionally catch deeper issues. * Not doing usrmerge variations for bookworm is consistent with the plan for the next release (though we should have usrmerge always enabled then, as opposed to only building with non-usrmerge). It is also similar to build paths (which are not tested in the "testing" suite), a lower bar for the "testing" suite, as it is a relatively easy thing to workaround for reproducibility. But, I've only caught a small part of this thread, so maybe there's more to it. :) live well, vagrant
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2021-08-17 19:00 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CNaBs-7D0-9@gated-at.bofh.it> |
| In reply to | #101091 |
tl;dr: I would prefer it if the usrmerge variation continues to be
exercised for the testing suite for the foreseeable future.
On Tue, 17 Aug 2021 at 09:16:01 -0700, Vagrant Cascadian wrote:
> The short of it, as I read it, is that non-usrmerge systems will be
> unsupported for bookworm, or did I misread that?
Assuming that TC resolution #978636 remains in effect:
There's unsupported, and there's unsupported; and I think we need to
distinguish between bookworm-as-testing, and bookworm-as-a-release.
For the reasons discussed elsewhere in this thread, the earliest point
at which package maintainers will be able to assume/require that their
package is installed onto a merged-/usr system is in around 2 years' time,
*after* bookworm r0, when the bookworm+1 cycle opens in testing/unstable.
This is because the packages that make up bookworm need to be installable
onto pre-bookworm, non-merged-/usr systems, otherwise we don't have an
upgrade path. We don't support skipping a release, so the packages in
bookworm+1 can safely assume that the system was fully upgraded to
bookworm first.
So for bookworm r0, we can *document* non-merged-/usr as unsupported,
and encourage/require/help users to transition systems to merged-/usr,
but in practice all the packages (except for those that are actively part
of the transition) need to behave as though it's still supported. When
the post-bookworm floodgates open and everyone is looking anxiously
at the buildd load graphs, *that* is the point at which packages can
validly start doing things that only work on merged-/usr systems. Does
that make sense?
> * Not doing usrmerge variations for bookworm is consistent with the plan
> for the next release (though we should have usrmerge always enabled
> then, as opposed to only building with non-usrmerge).
That variation is implemented by installing the usrmerge package, and
installing usrmerge has no effect on systems that are already merged-/usr;
so if a transition during the bookworm release cycle results in the
"base" bookworm chroot being merged-/usr already, that variation will
become meaningless but harmless. I think that's fine.
Until the "base" bookworm chroot becomes merged-/usr, please keep
applying usrmerge before the second build. We need to monitor the status
of packages whose contents differ when built on a merged-/usr system,
because as mentioned elsewhere in this thread, I think that needs to be
treated as a RC bug (if it isn't already). If packages vary in this way,
we need to get that variation fixed in testing, not just in unstable,
so having test coverage for that will be helpful.
Side note, I'm trying to be careful to distinguish between merged /usr
(a filesystem layout) and the usrmerge package (one implementation
of the transition from a non-merged-/usr filesystem to a merged-/usr
filesystem). You can have merged-/usr without ever having installed
usrmerge: new d-i installations of buster and bullseye are in that
situation.
smcv
[toc] | [prev] | [next] | [standalone]
| From | Holger Levsen <holger@layer-acht.org> |
|---|---|
| Date | 2021-08-17 19:20 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CNaUN-82N-1@gated-at.bofh.it> |
| In reply to | #101093 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, Aug 17, 2021 at 05:56:15PM +0100, Simon McVittie wrote: > tl;dr: I would prefer it if the usrmerge variation continues to be > exercised for the testing suite for the foreseeable future. ack, thanks (for the long version especially :) & agreed. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Just 100 companies are responsible for 71% of global emissions. https://www.theguardian.com/sustainable-business/2017/jul/10/100-fossil-fuel-companies-investors-responsible-71-global-emissions-cdp-study-climate-change
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <wouter@debian.org> |
|---|---|
| Date | 2021-08-16 16:10 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CMLto-8um-21@gated-at.bofh.it> |
| In reply to | #101012 |
On Fri, Aug 13, 2021 at 10:16:57AM +0100, Luca Boccassi wrote:
> 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.
We finished the /usr/doc transition in *exactly* this way. Yes it took
us longer, but we have better tools now.
So I call BS on "it will never finish".
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <wouter@debian.org> |
|---|---|
| Date | 2021-08-16 16:10 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CMLtn-8um-7@gated-at.bofh.it> |
| In reply to | #101009 |
On Fri, Aug 13, 2021 at 07:53:20AM +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.
In those cases, you would never run dpkg inside the system with the
"shared" /usr directory, so for those cases having /bin /sbin /lib* be
symlinks or real directories is irrelevant.
The point of having /bin etc not be a symlink is *to stop confusing
dpkg*. If you're talking about a system where dpkg will never run, then
that's irrelevant and you can just do whatever you want.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
[toc] | [prev] | [next] | [standalone]
| From | Marco d'Itri <md@Linux.IT> |
|---|---|
| Date | 2021-08-16 16:20 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CMLD3-5I-1@gated-at.bofh.it> |
| In reply to | #101054 |
[Multipart message — attachments visible in raw view] — view raw
On Aug 16, Wouter Verhelst <wouter@debian.org> wrote: > On Fri, Aug 13, 2021 at 07:53:20AM +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. > In those cases, you would never run dpkg inside the system with the > "shared" /usr directory, so for those cases having /bin /sbin /lib* be > symlinks or real directories is irrelevant. It is not irrelevant because then you would need to update /bin /sbin /lib* on the root file system when a new binary is added to the /usr file system (e.g. in an updated OS image). So I do not think that you understand well this use case. > The point of having /bin etc not be a symlink is *to stop confusing > dpkg*. This is a legitimate but very minor goal which could also be achieved by changing dpkg. -- ciao, Marco
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <wouter@debian.org> |
|---|---|
| Date | 2021-08-16 17:00 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CMMfM-iS-11@gated-at.bofh.it> |
| In reply to | #101058 |
On Mon, Aug 16, 2021 at 04:17:01PM +0200, Marco d'Itri wrote:
> On Aug 16, Wouter Verhelst <wouter@debian.org> wrote:
> > On Fri, Aug 13, 2021 at 07:53:20AM +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.
> > In those cases, you would never run dpkg inside the system with the
> > "shared" /usr directory, so for those cases having /bin /sbin /lib* be
> > symlinks or real directories is irrelevant.
> It is not irrelevant because then you would need to update /bin /sbin
> /lib* on the root file system when a new binary is added to the /usr
> file system (e.g. in an updated OS image).
> So I do not think that you understand well this use case.
My point is:
There is pushback against having usrmerge as the "default" thing,
because it confuses dpkg. Therefore some people would prefer a solution
that does not require all systems to have /bin etc be symlinks unless
and until the transition is complete.
This pushback however is only relevant for systems where dpkg will run.
If dpkg will not run, then dpkg cannot get confused, and so you *can*
have /bin etc be symlinks and it won't cause problems.
So "this is problematic for a case where dpkg will not run" is
irrelevant, as there you can do what you want and dpkg won't get
confused at all.
> > The point of having /bin etc not be a symlink is *to stop confusing
> > dpkg*.
> This is a legitimate but very minor goal which could also be achieved
> by changing dpkg.
Yes; but according to the dpkg maintainer, "changing dpkg" will take
much effort that may cause corner case bugs (including files
disappearing), and it would be easier (as in, faster and less likely to
cause problems) to try to do this in some other way. Perhaps he's wrong
at this (I don't know), but I haven't seen anyone take his concerns
seriously, and/or even try to come up with solutions to the concerns
that are raised.
Putting your hands in your ears and saying lalala it's not true is not
helping anyone.
(of course it might be that you have tried to do this and I've just
missed it, in which case just point me to the relevant bug)
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+debian-devel@zugschlus.de> |
|---|---|
| Date | 2021-08-17 19:10 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CNaL8-7XQ-21@gated-at.bofh.it> |
| In reply to | #101061 |
On Mon, 16 Aug 2021 16:56:34 +0200, Wouter Verhelst <wouter@debian.org> wrote: >There is pushback against having usrmerge as the "default" thing, >because it confuses dpkg. Therefore some people would prefer a solution >that does not require all systems to have /bin etc be symlinks unless >and until the transition is complete. In an ideal world, we would have the possibility to fix dpkg so that it doesn't get confused with this (predictable) state of the system any more. Greetings Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Sam Hartman <hartmans@debian.org> |
|---|---|
| Date | 2021-08-16 23:50 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CMSEx-4iR-1@gated-at.bofh.it> |
| In reply to | #101058 |
>>>>> "Marco" == Marco d'Itri <md@Linux.IT> writes:
Marco> This is a legitimate but very minor goal which could also be
Marco> achieved by changing dpkg.
I'm focus on your statement because I think you'll take the time to
consider what I have to say even if you ultimately disagree. I think
statements like the above escalate tension ain situations where we don't
want that.
It's obvious that different participants in the discussion prioritize
the goals differently.
It's really frustrating when you describe a goal that is important to
someone else as "very minor" or something similar.
It will instantly escalate tension.
Please respect the other participants by not trying to de-legitimize
their viewpoint.
It's fine to try and argue for project goals or goals of a sub group.
If Debian has decided that goal is "very minor," then I think your
statement would be less likely to escalate if you'd say that.
(In this instance I suspect Debian has explicitly decided no such
thing. Implicitly I agree that we have not chosen to wait for dpkg to
get fixed before moving forward on merged /usr. For a variety of
reasons I'd be happy to go into I don' think that is the same as Debian
deciding the goal is "very minor.")
If you think that goal is "very minor," then it's fine to say that. But
without qualifying the statement, you come across as placing your
opinion as fact, and in my experience that frustrates the people that
disagree with you. And when there is frustration, these threads get
longer.
Thanks for considering my thoughts here,
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <wouter@debian.org> |
|---|---|
| Date | 2021-07-27 17:10 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CFwSu-5UL-19@gated-at.bofh.it> |
| In reply to | #100877 |
On Tue, Jul 27, 2021 at 04:26:34PM +0200, Simon Richter wrote:
> Also, take care when moving shell commands from a shell script: the bash
> shell at least keeps a cache of commands to paths so it doesn't have to do a
> full path search every time. A shell script that calls
>
> mv /bin/cp /usr/bin/cp
> ln -s ../usr/bin/cp bin/cp
> mv /bin/ln /usr/bin/ln
> ln -s ../usr/bin/ln bin/ln
>
> could fall over because it cached the location of "ln" as /bin/ln in the
> beginning, then after the move cannot find it anymore. That needs at least a
> "hash -d ln".
This is why I said to use cp, not mv, when moving the file...
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
[toc] | [prev] | [next] | [standalone]
| From | Svante Signell <svante.signell@gmail.com> |
|---|---|
| Date | 2021-07-18 21:00 +0200 |
| Message-ID | <CCkb7-1wK-1@gated-at.bofh.it> |
| In reply to | #100739 |
On Wed, 2021-07-14 at 23:40 +0200, Guillem Jover wrote: > On Wed, 2021-07-14 at 19:54:56 +0000, Thorsten Glaser wrote: > > Sean Whitton dixit: > > > * #978636 move to merged-usr-only? > > > > > > We were asked to decide whether or not Debian 'bookworm' should > > > continue to support systems which are not using the merged-usr > > > filesystem layout. We decided that support should not continue > > > beyond Debian 'bullseye'. > > > > What? WHAT? ＷＨＡＴ？ > > > > > The decision is captured here: > > > <https://bugs.debian.org/978636#178> > > > > No reason provided either. This stinks. I’m v̲e̲r̲y̲ disappointed. > > Debian is becoming untenable. Years ago, I had hoped it won’t. > > I've been meaning to send a note about this for some time now, but > as I feel it keeps getting ignored, it always seems a bit pointless. > > But in any case, given that merged-usr-via-aliased-dirs is not really > supported by dpkg anyway, it is broken by design [B], I have no > intention whatsoever to break any of my systems with such layout > going forward, I'm thus planning to spend any necessary volunteer > time implementing any fix, workaround or solution required to avoid > having to use it, in detriment of other Debian volunteer time. I > alreadystarted some time ago with dpkg-fsys-usrunmess(8), present > already inthe upcoming bullseye release. > [B] https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Does_dpkg_support_merged-.2Fusr-via-aliased-dirs.3F > Since the dpkg developer and maintainer Guillem considers merged /usr broken by design, maybe Debian should consider to use some other package management software for the peace of mind for people involved in the project? Maybe guix could be usable?
[toc] | [prev] | [next] | [standalone]
| From | Polyna-Maude Racicot-Summerside <debian@polynamaude.com> |
|---|---|
| Date | 2021-07-18 23:50 +0200 |
| Message-ID | <CCmPE-38a-9@gated-at.bofh.it> |
| In reply to | #100790 |
[Multipart message — attachments visible in raw view] — view raw
Hi, On 2021-07-18 5:31 p.m., Svante Signell wrote: > Hi, is it OK to forward your mail to debian-devel. I don't think > mailing to debian-user will have any effect on this issue? > Sure ! Honestly it's my mistake to have sent it to debian-user. I get everything in one mailbox. I need to have this sorted out and use one mailbox for each mailing list. Thanks -- Polyna-Maude R.-Summerside -Be smart, Be wise, Support opensource development
[toc] | [prev] | [next] | [standalone]
| From | Polyna-Maude Racicot-Summerside <debian@polynamaude.com> |
|---|---|
| Date | 2021-07-19 00:00 +0200 |
| Message-ID | <CCmZl-3bq-7@gated-at.bofh.it> |
| In reply to | #100790 |
[Multipart message — attachments visible in raw view] — view raw
Hi, On 2021-07-18 5:07 p.m., Andy Smith wrote: > Hello, > > On Sun, Jul 18, 2021 at 04:31:11PM -0400, Polyna-Maude Racicot-Summerside wrote: >> My personal opinion is that Debian is going into a mostly "we got the >> best idea in the world but forgot that not everyone implement things the >> same way". > > I recommend understanding the issue before putting forth an opinion. > Maybe I shall correct what I said as it may be misunderstood. Without regard to this specific issue, I seem to have noticed that the Debian project has made some change in good faith, based on some technological conception of what is the best. But in the end, most user seem not to need those change and be a source of problem for most of them. I've had hell of a mess to understand the change to SystemD. Not so long ago I even learned that it caused a fork for a Debian derivative called Devuan. For me it was a huge departure from the KISS philosophy and I feel that this "usrmerge" is going the same way. I will take time to review what you have gave me as link and see what will be my opinion after this. >> I currently have a different partition for my /usr and this has been the >> case since the end of 1990s when I started on Linux. Maybe I'm wrong but >> I like it this way. >> >> Will the merge-usr cause myself problem ? > > No. Not as long as you use an initramfs created by any of the > supported Debian tools like initramfs-tools or dracut, which you > will do unless you have gone out of your way to do something > different. > I've did many Debian install, using the standard installation software, creating those partition from the "expert" choice of install mode. And never had problem, I believe that the initramfs tools must be doing their job. > And regardless of merged-/usr, /usr on separate partition has not > been supported in Debian without an initramfs since the stretch > release in 2017. > I've used Stretch with a separate /usr without much problem, as said above. > I think all of this is quite clearly explained in: > > https://salsa.debian.org/md/usrmerge/raw/master/debian/README.Debian > > which is linked from: > > https://wiki.debian.org/UsrMerge > > If you think it's not then you should probably raise a bug against > the usrmerge package with your suggested edits/clarifications. > > Andy > -- Polyna-Maude R.-Summerside -Be smart, Be wise, Support opensource development
[toc] | [prev] | [next] | [standalone]
| From | Andy Smith <andy@strugglers.net> |
|---|---|
| Date | 2021-07-19 01:50 +0200 |
| Message-ID | <CCoHL-4ko-3@gated-at.bofh.it> |
| In reply to | #100795 |
Hi, On Sun, Jul 18, 2021 at 05:54:33PM -0400, Polyna-Maude Racicot-Summerside wrote: > On 2021-07-18 5:07 p.m., Andy Smith wrote: > > I recommend understanding the issue before putting forth an opinion. > > > Maybe I shall correct what I said as it may be misunderstood. It's unclear to me why you've taken my reply to your mail on debian-user, and instead sent it to me privately and also to debian-devel. As neither of us are Debian Developers and you don't seem to have done much research regarding merged-/usr, I don't feel it is on-topic for me to continue that conversation with you on debian-devel. I recommend doing some more reading of these threads and the relevant wiki pages and if things are still unclear then asking user-level questions only on debian-user. Thanks, Andy
[toc] | [prev] | [next] | [standalone]
| From | Polyna-Maude Racicot-Summerside <debian@polynamaude.com> |
|---|---|
| Date | 2021-07-19 00:10 +0200 |
| Message-ID | <CCn8Z-3tV-1@gated-at.bofh.it> |
| In reply to | #100790 |
[Multipart message — attachments visible in raw view] — view raw
Hello (Hi) ! On 2021-07-18 5:07 p.m., Andy Smith wrote: > Hello, > > I think all of this is quite clearly explained in: > > https://salsa.debian.org/md/usrmerge/raw/master/debian/README.Debian > > which is linked from: > > https://wiki.debian.org/UsrMerge > > If you think it's not then you should probably raise a bug against > the usrmerge package with your suggested edits/clarifications. > I've read the link above plus the link to https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ So if I get it right... One partiton for /boot One partition for /usr One partition for /usr/local (if you feel like it) One / partiton that will contain not much stuff other than config files ? One partition for /var (if you feel) One partition for /opt, /srv ... One partition for /tmp The root partition can be small as 16 Gb as it won't contain much ? Am I getting this right ? Here's my actual partition table (2TB HD) udev 16G 0 16G 0% /dev tmpfs 3.2G 2.1M 3.2G 1% /run /dev/sda3 184G 70G 105G 40% / tmpfs 16G 163M 16G 2% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock /dev/sda5 262G 50G 199G 21% /var /dev/sda4 175G 86M 166G 1% /tmp /dev/sda8 88G 60M 83G 1% /usr/local /dev/sda7 92G 3.6G 84G 5% /opt /dev/sda10 92G 60M 87G 1% /srv /dev/sda1 487M 3.3M 483M 1% /boot/efi /dev/sda11 733G 649G 47G 94% /home I currently have a 70G usage of the root partition. Running Buster. > Andy > -- Polyna-Maude R.-Summerside -Be smart, Be wise, Support opensource development
[toc] | [prev] | [next] | [standalone]
Page 11 of 13 — ← Prev page 1 … 9 10 [11] 12 13 Next page →
Back to top | Article view | linux.debian.devel
csiph-web