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 8 of 13 — ← Prev page 1 … 6 7 [8] 9 10 … 13 Next page →
| From | Simon Richter <sjr@debian.org> |
|---|---|
| Date | 2021-08-22 17:10 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <COXgL-2UC-21@gated-at.bofh.it> |
| In reply to | #101267 |
[Multipart message — attachments visible in raw view] — view raw
Hi,
On 22.08.21 05:10, Theodore Ts'o wrote:
> So with the goal of trying to enumerate possible solutions, it sounds
> some combination of:
> (a) disallowing moving problematic files between packages, with possibly some
> QA tools to enforce this
> (b) keeping the next release cycle *short*, say only a year
> (c) requiring that dpkg be upgraded first, and having dpkg and
> related tools understand the concept of usrmerge and the
> fact that /{bin,lib,sbin} and /usr/{bin,lib,sbin} are identical
> for usrmerged systems
> might be possible paths forward. Do you agree?
Yes. I'd even say that if we don't have any problematic moves, we can
get away with updating dpkg at any point during the upgrade -- the
current state is more "fragile" than "broken", which would help
immensely because we don't have to expend manpower on updating
autobuilders and explaining to people that dist-upgrade is not to be used.
> What are other possible solutions?
Current dpkg already has handling code so that /bin/foo -> /usr/bin/foo
is not a problematic move even on usrmerge'd systems, so a possible
policy would be to allow those and disallow package splits, that way we
could continue transitioning packages. If we manage to move all files
out, the discrepancy between the dpkg database and the filesystem will
be minimal (but we can't transition libc6 that way, because usrmerge
left us with a state where we can't unpack a libc6 that provides ld.so
as a symlink in /lib).
The approach that will take the least amount of work but is a nasty
horrible hack would be to integrate usrmerge into dpkg, forcibly
converting any system that isn't yet, updating the dpkg database in
either case, and then filtering file lists during writing going forward.
I'd rather not try to make the conflict checking code itself understand
aliasing through symlinks, that looks as if it would be a source of
bugs, but transforming file lists to canonical paths before checking
should be doable, and any symlink-vs-directory conflict outside those we
explicitly handle then become fatal instead of silently ignored.
The most generic approach would be to have a symlink farming mode in
dpkg, where it has a goal (as defined by a package) to create a symlink
/lib -> usr/lib, but while another package declares /lib to be a
directory, the directory has precedence and dpkg generates the minimal
set of symlinks that create the same effect -- so if /usr/lib/foo exists
and /lib/foo doesn't, it generates a symlink /lib/foo -> ../usr/lib/foo.
This would allow us to transition the package contents to match reality
on usrmerged systems, and dpkg will finish the transition as the last
package that declares /lib to be a directory is gone, and it could be
used for any future transitions that need old paths to work for a while.
Without an extra hack, this would not allow us to transition ld.so out
of /lib though because
/usr/lib/ld-linux.so.2
/lib -> usr/lib
would be unpacked without the symlink because the file conflict causes
the symlink to be dropped.
Simon
[toc] | [prev] | [next] | [standalone]
| From | Simon Richter <sjr@debian.org> |
|---|---|
| Date | 2021-08-22 21:10 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CP110-5m4-3@gated-at.bofh.it> |
| In reply to | #101281 |
Hi,
On 22.08.21 16:52, Simon Richter wrote:
> The most generic approach would be to have a symlink farming mode in
> dpkg, where it has a goal (as defined by a package) to create a symlink
> /lib -> usr/lib, but while another package declares /lib to be a
> directory, the directory has precedence and dpkg generates the minimal
> set of symlinks that create the same effect -- so if /usr/lib/foo exists
> and /lib/foo doesn't, it generates a symlink /lib/foo -> ../usr/lib/foo.
Hmm, this could work with a Pre-Depends from base-files/bookworm to
dpkg/bookworm, and base-files/bookworm providing the /bin, /lib and
/sbin symlinks to indicate to dpkg that this is desired.
base-files has sufficiently few rdepends that it can be updated rather
late, but it is Essential: yes, so it is guaranteed to be available on
new installations (which would also have a dpkg that understands it).
So a rule to resolve symlink-vs-directory conflicts would change from
"ignore the symlink" to "build a symlink farm that tries to make the
same paths available", and the symlink farm would be optimized as
packages drop directories.
So e.g. if I have two kernel packages with
/lib/modules/1.2.3
and
/usr/lib/modules/1.2.4
then the desired symlink in base-files
/lib -> usr/lib
would conflict with /lib in the kernel package, and dpkg resolves this
to /lib/modules -> ../usr/lib/modules (still a conflict), then to
/lib/modules/1.2.4 -> ../../usr/lib/modules/1.2.4, which can be created
to make the modules in /usr/lib available from /lib as if /lib was
symlinked.
When the package providing /lib/modules/1.2.3 is removed, the last
package providing /lib/modules is gone, so we can replace this with a
symlink /lib/modules -> ../usr/lib/modules.
The transition is finished when the last package that uses /lib as a
directory is gone. That will be libc6, which still has to provide ld.so
in the usual path even in bookworm.
For systems that are usrmerged, the symlink is already as dpkg expects,
so it doesn't start symlink farming there. We can use the bookworm cycle
to move files to /usr as long as we don't move them to other packages,
so we'd be getting fairly close to getting the database and the
filesystem consistent after the upgrade -- basically everything but
libc6 would be finished in bookworm.
The second thing is that we cannot deprecate scanning old paths during
the bookworm cycle -- so systemd needs to continue looking into
/lib/systemd, so the transition will not be finished during the bookworm
cycle anyway.
Simon
[toc] | [prev] | [next] | [standalone]
| From | "Theodore Ts'o" <tytso@mit.edu> |
|---|---|
| Date | 2021-08-24 02:50 +0200 |
| Subject | Making the dpkg database correspond with reality (Was Re: merged /usr vs. symlink farms) |
| Message-ID | <CPsNz-5tf-1@gated-at.bofh.it> |
| In reply to | #101288 |
I want to ask a potentially stupid question.
As I understand things, the problem is that in a usrmerge'd file
system where we have the top-level symlinks /{bin,lib,sbin} which
point at /usr/{bin,lib,sbin}, the problem is if we have a package
which contains the file in /sbin/blart, it gets installed in
/usr/sbin/blart thanks to the symlink, but the dpkg database has an
entry for /sbin/blart, and that is the conflict which is the problem.
So.... in theory, if we had a program which looked for the top-level
symlinks /{bin,lib,sbin} -> /usr/{bin,lib,sbin}, and if they exist,
scans dpkg database is scanned looking for of the form
/{bin,lib,sbin}/$1, and updates them with /usr/{bin,lib,sbin}/$1, and
then in the future, if dpkg sees the top-level symlink, canonicalizes
any files referenced in the packages to /usr/{bin,lib,sbin}/$1, with a
fallback searching for /{bin,lib,sbin}/$1 in the file system, this
would solve the problem.
Let's ignore how we would deploy this helper program and the update
dpkg from a stable upgrade perspective, but in terms of preventing
potential problems during the testing window, getting an update to
dpkg which included the database fixup program and which ran from the
maintainer script would be a potential solution path.
Furthermore, if dpkg knew to always canonicalize filenames from
/{bin,lib,sbin}/XXX to /usr/{bin,lib,sbin}XXX when adding to the
database, and when it looked for files in the file system looked first
in /usr/{bin,lib,sbin}/XXX, with a fallback to /usr/{bin,lib,sbin}/XXX
the file names in the package would not need to change all, since all
of the magic fixup work would be happening inside dpkg.
Is this a viable path forward, or am I missing something?
Thanks,
- Ted
[toc] | [prev] | [next] | [standalone]
| From | Timo Röhling <roehling@debian.org> |
|---|---|
| Date | 2021-08-24 08:50 +0200 |
| Subject | Re: Making the dpkg database correspond with reality (Was Re: merged /usr vs. symlink farms) |
| Message-ID | <CPypX-JQ-5@gated-at.bofh.it> |
| In reply to | #101336 |
[Multipart message — attachments visible in raw view] — view raw
Hi, * Theodore Ts'o <tytso@mit.edu> [2021-08-23 20:48]: >I want to ask a potentially stupid question. > [...] This is pretty much what I was wondering about in https://lists.debian.org/debian-devel/2021/08/msg00372.html You, however, phrased it much more eloquently than I could. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯
[toc] | [prev] | [next] | [standalone]
| From | Simon Richter <sjr@debian.org> |
|---|---|
| Date | 2021-08-24 12:00 +0200 |
| Subject | Re: Making the dpkg database correspond with reality (Was Re: merged /usr vs. symlink farms) |
| Message-ID | <CPBnP-2IT-7@gated-at.bofh.it> |
| In reply to | #101336 |
[Multipart message — attachments visible in raw view] — view raw
Hi,
On 8/24/21 2:48 AM, Theodore Ts'o wrote:
> So.... in theory, if we had a program which looked for the top-level
> symlinks /{bin,lib,sbin} -> /usr/{bin,lib,sbin}, and if they exist,
> scans dpkg database is scanned looking for of the form
> /{bin,lib,sbin}/$1, and updates them with /usr/{bin,lib,sbin}/$1, and
> then in the future, if dpkg sees the top-level symlink, canonicalizes
> any files referenced in the packages to /usr/{bin,lib,sbin}/$1, with a
> fallback searching for /{bin,lib,sbin}/$1 in the file system, this
> would solve the problem.
Yes. To apply the transformation, this would likely have to happen in
the dpkg package itself, so the one-time transformation is applied only
when dpkg can maintain the workaround from that point on.
That is the half that is missing from my proposal, as I was focusing on
how to transition non-usrmerged systems from within dpkg.
> Let's ignore how we would deploy this helper program and the update
> dpkg from a stable upgrade perspective, but in terms of preventing
> potential problems during the testing window, getting an update to
> dpkg which included the database fixup program and which ran from the
> maintainer script would be a potential solution path.
Yes-ish. We'd also need to make sure that installing the usrmerge
package after that dpkg upgrade does not make things inconsistent again,
so it would make sense for the dpkg source package to provide a
"usrmerge" package that is well integrated, and for dpkg to conflict
with older versions of usrmerge.
> Furthermore, if dpkg knew to always canonicalize filenames from
> /{bin,lib,sbin}/XXX to /usr/{bin,lib,sbin}XXX when adding to the
> database, and when it looked for files in the file system looked first
> in /usr/{bin,lib,sbin}/XXX, with a fallback to /usr/{bin,lib,sbin}/XXX
> the file names in the package would not need to change all, since all
> of the magic fixup work would be happening inside dpkg.
Yes. In an ideal world, we wouldn't hardcode the list of symlinks in
dpkg though, that's why I proposed shipping symlinks in base-files and
having dpkg recognize the symlink-vs-directory conflict as intent to
move a filesystem tree around.
Simon
[toc] | [prev] | [next] | [standalone]
| From | "Theodore Ts'o" <tytso@mit.edu> |
|---|---|
| Date | 2021-08-24 16:50 +0200 |
| Subject | Re: Making the dpkg database correspond with reality (Was Re: merged /usr vs. symlink farms) |
| Message-ID | <CPFUu-5BN-17@gated-at.bofh.it> |
| In reply to | #101338 |
On Tue, Aug 24, 2021 at 11:57:27AM +0200, Simon Richter wrote:
> Hi,
>
> On 8/24/21 2:48 AM, Theodore Ts'o wrote:
>
> > So.... in theory, if we had a program which looked for the top-level
> > symlinks /{bin,lib,sbin} -> /usr/{bin,lib,sbin}, and if they exist,
> > scans dpkg database is scanned looking for of the form
> > /{bin,lib,sbin}/$1, and updates them with /usr/{bin,lib,sbin}/$1, and
> > then in the future, if dpkg sees the top-level symlink, canonicalizes
> > any files referenced in the packages to /usr/{bin,lib,sbin}/$1, with a
> > fallback searching for /{bin,lib,sbin}/$1 in the file system, this
> > would solve the problem.
>
> Yes. To apply the transformation, this would likely have to happen in the
> dpkg package itself, so the one-time transformation is applied only when
> dpkg can maintain the workaround from that point on.
Sure, since we're talking about dpkg database surgery, it's better
that the sources of such a program be located in the dpkg sources, and
regardless of who does the work, the dpkg maintainers should be
involved in the code review of any such change.
> That is the half that is missing from my proposal, as I was focusing on how
> to transition non-usrmerged systems from within dpkg.
I've been more focused on the usrmerged systems since nearly all of my
personal systems are already usrmerged, since I tend to reinstall my
systems whenver I upgrade my hardware, and deboostrap has installing
systems with the usrmerge top-level symlinks since Buster.
Furthermore, people have been arguing strenuously that the possibility
of file loss is real for these usrmerged systems, so fixing this
seemed to be high priority, regardless of how many systems use the
usrmerge setup.
So protecting against lost files was higher priority in my mind,
whether the people arguing that it's rare because Ubuntu users having
been losing files, or not, I accept the argument that if it can happen
(and you've demonstrated via adversarial test cases that it *can*), we
should fix that bug, whether it's considered an RC bug or not.
(Although my personal belief is that we should be a lot more open to
fixing less critical bugs in stable releases, so if we have a fix, I'd
be all for rolling it out early to Bullseye regardless of whether it's
considered "RC" or not.)
> > Let's ignore how we would deploy this helper program and the update
> > dpkg from a stable upgrade perspective, but in terms of preventing
> > potential problems during the testing window, getting an update to
> > dpkg which included the database fixup program and which ran from the
> > maintainer script would be a potential solution path.
>
> Yes-ish. We'd also need to make sure that installing the usrmerge package
> after that dpkg upgrade does not make things inconsistent again, so it would
> make sense for the dpkg source package to provide a "usrmerge" package that
> is well integrated, and for dpkg to conflict with older versions of
> usrmerge.
I'm less worried about whether usrmerge is part of dpkg or not, since
most of my usrmerged systems are due to them being reinstalled since
Debian Buster has been around, and the definition of usrmerged is
relatively well understood (symlinks for /{bin,lib,sbin} to
/usr/{bin,lib,sbin}). But it wouldn't hurt for dpkg to provide its
own "usrmerge" functionality, and I certainly wouldn't argue against it.
> > Furthermore, if dpkg knew to always canonicalize filenames from
> > /{bin,lib,sbin}/XXX to /usr/{bin,lib,sbin}/XXX when adding to the
> > database, and when it looked for files in the file system looked first
> > in /usr/{bin,lib,sbin}/XXX, with a fallback to /usr/{bin,lib,sbin}/XXX
> > the file names in the package would not need to change all, since all
> > of the magic fixup work would be happening inside dpkg.
>
> Yes. In an ideal world, we wouldn't hardcode the list of symlinks in dpkg
> though, that's why I proposed shipping symlinks in base-files and having
> dpkg recognize the symlink-vs-directory conflict as intent to move a
> filesystem tree around.
That's certainly the more general solution, although again, I think
the definition of usrmerge is well understood, especially since Debian
has been on the trailing edge of the usrmerge transition across the
Linux ecosystem, and so the high priority should be for fixing the
specific case of moving the contents to /{bin,lib,sbin} to
/usr/{bin,lib,sbin} and leaving symlinks behind for the directories.
If we want to support people who want to say, move /usr/bin to
/u1/bin, and /usr/lib to /u2/lib, or even /usr/lib/X11 to
/funky/dir/X11, great! Personally, I wouldn't consider that a high
priority item on the requirements list, though, unless it comes
essentially for free.
Cheers,
- Ted
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2021-08-24 20:00 +0200 |
| Subject | Re: Making the dpkg database correspond with reality (Was Re: merged /usr vs. symlink farms) |
| Message-ID | <CPISl-7xU-5@gated-at.bofh.it> |
| In reply to | #101339 |
On Tue, 24 Aug 2021 at 10:46:45 -0400, Theodore Ts'o wrote:
> the definition of usrmerged is
> relatively well understood (symlinks for /{bin,lib,sbin} to
> /usr/{bin,lib,sbin})
For completeness: also /libQUAL to usr/libQUAL, for each libQUAL
that either participates in multilib or contains ld.so(8). See
setup_merged_usr() in debootstrap/functions or directories_to_merge()
in usrmerge/convert-usrmerge.
(For x86_64 users this means lib32, lib64 and libx32.)
smcv
[toc] | [prev] | [next] | [standalone]
| From | Sam Hartman <hartmans@debian.org> |
|---|---|
| Date | 2021-08-23 16:20 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CPiXU-81x-1@gated-at.bofh.it> |
| In reply to | #101281 |
[Multipart message — attachments visible in raw view] — view raw
>>>>> "Simon" == Simon Richter <sjr@debian.org> writes:
Simon> Current dpkg already has handling code so that /bin/foo ->
Simon> /usr/bin/foo is not a problematic move even on usrmerge'd
Simon> systems, so a possible policy would be to allow those and
Simon> disallow package splits, that way we could continue
Simon> transitioning packages.
Why would we need to transition packages?
If we're going to have something like usrmerge run eventually,
It seems like things will be much simpler if we forbid or at least
strongly discourage package level transitions in the bookworm cycle.
Doing that seems to be closer to the consensus of what we're discussing
here than spending effort transitioning packages.
[toc] | [prev] | [next] | [standalone]
| From | Timo Röhling <roehling@debian.org> |
|---|---|
| Date | 2021-08-22 12:20 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <COSK5-5m-5@gated-at.bofh.it> |
| In reply to | #101266 |
[Multipart message — attachments visible in raw view] — view raw
Hi,
* Simon Richter <sjr@debian.org> [2021-08-22 02:15]:
>There are two issues here: dpkg not handling certain corner cases, and
>the usemerge package modifying the file system, bypassing dpkg.
Maybe this question has been answered elsewhere, but I keep
wondering: What prevents dpkg from updating/reparing its database
to match what usrmerge did? It's not like files got shifted around
arbitrarily.
The database rewrite would be irreversable, but switching back and
forth is not a required feature anyway. And the rewrite is
idempotent, so it might even be possible to run this unconditionally
as part of some future release upgrade.
Of course, dpkg would need a path canonicalization that
transparently maps /{bin,lib*,sbin} to /usr/{bin,lib*,sbin} on *all*
file operations and is enabled together with the database
conversion. This might take some effort to code, mostly because it
must be applied consistently. Still, it's best to have this done
right in dpkg once and for all, and I'm probably not the only one
who would be willing to help.
Cheers
Timo
--
⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯
[toc] | [prev] | [next] | [standalone]
| From | "Theodore Ts'o" <tytso@mit.edu> |
|---|---|
| Date | 2021-08-21 18:50 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <COClY-6zk-7@gated-at.bofh.it> |
| In reply to | #101238 |
On Sat, Aug 21, 2021 at 10:26:13AM +0200, Wouter Verhelst wrote: > It bothers me that you believe "we've been doing this for a while and it > didn't cause any problems, so let's just continue doing things that way > even if the people who actually wrote the damn code say that path is > littered with minefields and they're scared of what could happen when we > finish the tranition this way" is a valid strategy. It goes against > everything I was taught to do to write reliable software. So as an expert, what's your recommendation about what is to be done? Personally, I *don't* have a problem about telling people to manually update dpkg, apt, and/or apt-get before they do the next major stable release (maybe it's because this is something I do as a matter of course; it's not that much extra effort, and I'm a paranoid s.o.b., and I know that's the most tested path given how Debian testing works). Other people think that is a terrible idea, to be avoided at all costs. I don't understand why that is such a terrible outcome, since I do it already, but perhaps I can be educated on that point. In any case, I believe downsides of the symlink farm alternative are greater than the downsides of other options: * just living with the risk of potential corner cases which might affect users when they do the bullseye -> bookworm upgrade, since aparently the sky hasn't fallen with Ubuntu, or * advise users to upgrade dpkg/apt/apt-get first when they do the next release, with the strength of that advice depending on how likely users are to suffer from a "mine" causing their system to lose a limb or two. Heck, if the minefield is that dangerous (and if so, why the *heck* aren't Ubuntu users screaming from data loss, system instability, etc?), perhaps you should advise the release managers that dpkg needs to have fixes pushed out to Bullseye NOW! NOW! NOW! to eliminate the potential imminent damage that you seem to be so fearful of our users might get hit with. Can you give more details about real life scenarios which is triggering your fears, and whether there are ways we can mitigate against those scenarios? Best regards, - Ted
[toc] | [prev] | [next] | [standalone]
| From | David Kalnischkies <david@kalnischkies.de> |
|---|---|
| Date | 2021-08-22 12:30 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <COSTL-8B-7@gated-at.bofh.it> |
| In reply to | #101257 |
[Multipart message — attachments visible in raw view] — view raw
On Sat, Aug 21, 2021 at 12:47:51PM -0400, Theodore Ts'o wrote: > Personally, I *don't* have a problem about telling people to manually > update dpkg, apt, and/or apt-get before they do the next major stable > release (maybe it's because this is something I do as a matter of > course; it's not that much extra effort, and I'm a paranoid s.o.b., So, when did you last log into your build chroot to upgrade dpkg and apt first? And while at that, did you follow the release notes – from the future, as they have yet to be written for the release you are arguably upgrading to already? But okay, lets assume you actually do: apt and dpkg tend not to be statically linked, so they end up having dependencies. Some of them even surprising. In bullseye you e.g. have to upgrade cryptsetup first before apt can be upgraded (apt → libgcc-s1 → cryptsetup-initramfs → …). And that is just the first and most obvious chain. But it would never happen that you would e.g. need to upgrade all of the KDE desktop environment before upgrading dpkg, right? Well… in Debian squeeze that nearly happened, but we had to break that chain because it was actually forming a 500+ loop apt/lenny had trouble dealing with. Those chains are only investigated if they lead to major problems: I e.g. never looked at the C++ v5 (copy on write) transition which likely entangled apt with half of the universe in the general case. But okay, lets assume we form a team who actually looks into all these. It is easy, right? No. Dependencies and their version constrains (can) differ by architecture and mostly propagate by negative dependencies meaning the individual system state is hugely important. The result is that hardly any upgrade is the same even if we subsume it all under "upgrade to bullseye". And regardless of how hard we try, there will always be other packages which have to go before it is dpkgs turn, so at least all these have to make due with what was released previously anyhow. > and I know that's the most tested path given how Debian testing > works). Not really as you can see e.g. with libgcc-s1, as most upgrade problems aren't due to dpkg or apt in practice, but because the intermediate steps of a package making testing upgrades a smooth sail aren't visible for the stable updates. If you want a better tested path, I suggest stable updates by jumping from week to week via snapshot.d.o. You may want to skip weeks with actual bugs through. In the end, it is just simpler to assume that every release+1 package is installed by dpkg/release (and of course apt/release) than trying to reason if and how we can make it happen that dpkg is handled before some other package (without forming loops) or even can be sanely upgraded ahead of the upgrade entirely. Or are you perhaps volunteering? Don't get me wrong, as an apt dev I would love if we could do that. It is kinda annoying to work around issues you have fixed years ago, but aren't available in (soon) oldstable. We would need a more aggressive stable-updates strategy but in reality we tend to be held to even higher standards than all other packages because we are native key packages… (just look when we froze dpkg… apt at least has a tiny loophole for now by not being build-essential in a strict sense) Not that it really matters. It would just add more moving parts to the upgrade process – a process, if this entire thread is any indication, which is hardly understood by anyone in Debian and considered entirely optional by many. That alone makes me very sad on many levels. (I wrote this before reading Guillems replies which end on a similar note even though he comes from the opposite end – dpkg worried about the finer file-level details and apt about the general package-level picture meeting halfway as usual… kinda funny) Best regards David Kalnischkies P.S.: As someone will ask: Ubuntu splits the user base in two: Those who run their release upgrader which runs outside of the packaging system and largely can do whatever (including bring in a standalone apt/dpkg just dealing with an upgrade – they usually resign to much simpler things through) and those who don't like for example chroots and containers who effectively use whatever an upgrade path 'apt dist-upgrade' gives you. Which also explains why Ubuntu hasn't fully /usr-merged yet more or less waiting for Debian to figure that one out. Or, well, they spearhead even here now as it is apparently too much to ask for an upgrade path in Debian nowadays.
[toc] | [prev] | [next] | [standalone]
| From | "Theodore Ts'o" <tytso@mit.edu> |
|---|---|
| Date | 2021-08-23 01:10 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CP4Lg-7Gf-13@gated-at.bofh.it> |
| In reply to | #101275 |
On Sun, Aug 22, 2021 at 12:26:46PM +0200, David Kalnischkies wrote: > > So, when did you last log into your build chroot to upgrade dpkg and > apt first? And while at that, did you follow the release notes – from > the future, as they have yet to be written for the release you are > arguably upgrading to already? Personally, I never upgrade build chroots between major versions. I just use a tool like sbuild-createchroot to create them from scratch. That's mainly because I need to keep the Buster chroot around for backports, so I'll just create a new Bullseye chroot when I need it. And of course my unstable chroot is continuously being upgraded but that avoids most of the concerns people have about the Debian N to N+1 stable upgrade path. > But okay, lets assume you actually do: apt and dpkg tend not to be > statically linked, so they end up having dependencies.... So on my "pet" production systems (on my "cattle" systems I just recreate them from scratch, e.g. "gce-xfstests create-image"[1] which uses deboostrap), what I do is update /etc/apt/sources.list, and then do "apt update ; apt-get install dpkg ; apt-get install apt" before I run "apt-get dist-upgrade". This handles the dependencies for me, and while a few packages will get upgraded using the old dpkg and apt, the vast majority of the packages will get upgraded using the latest stable version of dpkg and apt. This seems like relatively cheap insurance; it doesn't hurt, and it might help avoid some nasty corner cases that got overlooked during testing. [1] https://thunk.org/gce-xfstests > Don't get me wrong, as an apt dev I would love if we could do that. It > is kinda annoying to work around issues you have fixed years ago, but > aren't available in (soon) oldstable. Well, I'll observe that if we told people to upgrade dpkg and apt first using "apt-get install ...", this automatically handles the dependencies, and while it doesn't make *all* of the potential issues go away, I would think it would reduce the potential corner cases and hence make it easier to test to make sure the right thing happens on an update from Debian vN to vN+1, would it not? > P.S.: As someone will ask: Ubuntu splits the user base in two: Those who > run their release upgrader which runs outside of the packaging system and > largely can do whatever (including bring in a standalone apt/dpkg just > dealing with an upgrade – they usually resign to much simpler things > through) and those who don't like for example chroots and containers who > effectively use whatever an upgrade path 'apt dist-upgrade' gives you. ... and in my opinion, that's a *fine* strategy. Sure, it would be nice if "apt dist-upgrade" always worked smoothly, and that's a great aspirational goal, but if we can reduce risks to users --- particularly non-technical/non-expert users --- by using a release upgrader which upgrades apt and dpkg first, we should do that. So let's take a page from Ubuntu, by all means! - Ted
[toc] | [prev] | [next] | [standalone]
| From | gregor herrmann <gregoa@debian.org> |
|---|---|
| Date | 2021-08-23 02:50 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CP6k1-8rj-1@gated-at.bofh.it> |
| In reply to | #101296 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, 22 Aug 2021 19:02:18 -0400, Theodore Ts'o wrote: > On Sun, Aug 22, 2021 at 12:26:46PM +0200, David Kalnischkies wrote: > > So, when did you last log into your build chroot to upgrade dpkg and > > apt first? > Personally, I never upgrade build chroots between major versions. I > just use a tool like sbuild-createchroot to create them from scratch. That's one option, the other (and faster) is, quoting from ~/.bash_history from a week ago: #v+ cp -ar amd64/bullseye-base.cow amd64/bookworm-base.cow cp -ar i386/bullseye-base.cow i386/bookworm-base.cow sed -i -e 's/bullseye/bookworm/g' amd64/bookworm-base.cow/etc/apt/sources.list i386/bookworm-base.cow/etc/apt/sources.list ./update_all_cow.sh # wrapper around `cowbuilder --update --basepath …' for all cowbuilder chroots #v- Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `-
[toc] | [prev] | [next] | [standalone]
| From | Sam Hartman <hartmans@debian.org> |
|---|---|
| Date | 2021-08-20 16:00 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <COddT-7KH-5@gated-at.bofh.it> |
| In reply to | #101178 |
[Multipart message — attachments visible in raw view] — view raw
>>>>> "Theodore" == Theodore Ts'o <tytso@mit.edu> writes:
Theodore> On Thu, Aug 19, 2021 at 11:17:17AM +0100, Simon McVittie wrote:
>> In this specific case, I think the thing you're having a problem
>> with is the gradual, file-by-file migration of executables into
>> /usr by individual packages and individual packages'
>> maintainers. That's not merged-/usr: merged-/usr does the
>> migration all at once, by creating the aliasing symlinks (and
>> then we can clean up the contents of data.tar.* to put all
>> /usr-like files below /usr at our leisure, during the next
>> release cycle, without needing maintainer script glue).
Theodore> FWIW, from following the discussion, I've become more and
Theodore> more convinced that a symlink farm is *not* the right
Theodore> answer, regardless of whether it is done centrally or via
Theodore> individual packages moving files and created symlinks if
Theodore> necessary in individual maintainer scripts.
Ted, in terms of judging consensus, I'd like to explicitly ACK your
summary.
I think that you have accurately described where we are in the
discussion.
As you know, one of the ways we can see how close we are on consensus
is to look at what happens when someone proposes a summary like you did.
Simon Richter tried to challenge your summary effectively saying that we
couldn't have an informed consensus because there were open technical
issues that had not been addressed. This was roundly rejected by
yourself, Philip Hands and Luca Boccassi.
Simon's position seemed to be that we need a dpkg update in order to
move forward and that we cannot depend on that mid-release.
You talked about ways we could get a dpkg update at the beginning of the
release process.
Luca and Philip made more structural objections.
Simon did not clearly explain *why* we need a dpkg update.
I can see two arguments why we might need a dpkg update:
1) To fix bugs related to directory aliasing.
I don't think that there is a consensus those bugs need to be fixed to
move forward. (Put another way it's not clear the community agrees they
are RC).
IN particular, most systems are usrmerged today, and while these bugs
are annoying, many people get along just fine.
Yes, there are bugs.
Yes, it would be good to get them fixed in the bookworm cycle.
But despite the issue being brought up, there is not strong support for
the idea that we must block on a solution to the dpkg directory aliasing
bugs.
2)
We might need a dpkg update to actually do the transition.
Thatt is somehow dpkg mechanisms replace what the usrmerge package
does. Or alternatively dpkg mechanisms give us a facility to run
usrmerge early enough.
It's absolutely true that there is an open technical issue of how to
trigger the transition.
However, there are proposed solutions under development that in terms of
being favored in a consensus discussion are preferable to
usr-merge-via-symlink farms:
A) An extraordinary upgrade process. For example requiring that if you
are running on a system that is not usrmerged already, you need to
install usrmerge at the beginning of the upgrade.
(it could still be transitively essential, but explicitly asking people
where it matters to install early).
b) Require that bookworm packages work on non-usrmerged systems and
support non-usrmerged build chroots in the bookworm cycle.
None of these solutions are ideal.
There is still technical work to do, and there a absolutely are open
technical issues.
My reading of the discussion is the same as yours though. We have an
informed consensus that usrmerge-via-symlinks is not the direction we
should take.
I recognize that there are people who are not part of that consensus:
Simon Richter and Guillem Jover among them.
I think the project has given people who are in the rough an opportunity
to present their objections and has taken the time to understood
technical objections that were presented.
I also agree with your reading of the history that there were process
problems in how we interacted with the dpkg team.
I agree with you that is water under the bridge in terms of our
technical decision today.
I hope we choose to learn from that for better future decision making,
but I do not think either our users or the free software community would
be served by letting those process concerns stop technical progress.
[toc] | [prev] | [next] | [standalone]
| From | "Theodore Ts'o" <tytso@mit.edu> |
|---|---|
| Date | 2021-08-20 20:00 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <COgYa-1Bo-19@gated-at.bofh.it> |
| In reply to | #101204 |
On Fri, Aug 20, 2021 at 07:56:33AM -0600, Sam Hartman wrote:
> As you know, one of the ways we can see how close we are on consensus
> is to look at what happens when someone proposes a summary like you did.
Thanks, that was my goal: trying to see if we could move the
discussion towards some kind of community consensus.
> Simon Richter tried to challenge your summary effectively saying that we
> couldn't have an informed consensus because there were open technical
> issues that had not been addressed. This was roundly rejected by
> yourself, Philip Hands and Luca Boccassi.
>
> Simon's position seemed to be that we need a dpkg update in order to
> move forward and that we cannot depend on that mid-release.
>
> You talked about ways we could get a dpkg update at the beginning of the
> release process.
> Luca and Philip made more structural objections.
>
> Simon did not clearly explain *why* we need a dpkg update.
Fair enough. I am unclear on whether we need a dpkg update; I do
believe, though, that even if we needed a dpkg update for some reason,
though, we should explore options other than /usr unification via
symlink farms, which I continue to believe is highly undesirable
choice.
> I can see two arguments why we might need a dpkg update:
>
> 1) To fix bugs related to directory aliasing.
>
> I don't think that there is a consensus those bugs need to be fixed to
> move forward. (Put another way it's not clear the community agrees they
> are RC).
Actually, I think we can make a stronger statement than that. Even if
the dpkg bugs relating to directory aliasing which are release
critical in terms of severity (and it's unclear to me whether they
rise to that level), the specifically germane question is whether they
have to be fixed *before* proceeding with the bullseye->bookworm
update. After all, it might be that say, "dpkg-query -S" can fail[1],
but even *if* this were considered priority "serious" --- which I do
not believe --- if it doesn't break upgrading systems, then it can be
fixed when dpkg is upgraded, and we don't have to upgrade dpkg first.
(And again, is it *really* that bad if we tell users that it is
advisable to upgrade dpkg first? TBH, I very often will upgrade dpkg
and apt by hand, before running "apt dist-upgrade" to this day,
because of past experience from upgrades long, long ago... Maybe it's
a cargo cult practice, like typing "sync" three times, but it's not
that hard!)
So perhaps one path forwarwd is to example the breakages listed in
[1], and consider how likely any of them are likely to break upgrades.
I will admit that concerns around update-alternatives and dpkg-divert
sound the scariest --- but I've been using a usrmerged system for a
while, and nothing as broken for me. And as others have pointed out,
Ubuntu has been using usrmerged systems exclusively for a while now,
"going behind dpkg's back", and there doesn't seem to have been a lot
of reports of disaster befalling Ubuntu. Is there things they are
doing to mitigate the potential problems around dpkg-divert and
update-alternatives? What can we learn from the Ubuntu experience?
[1] https://wiki.debian.org/Teams/Dpkg/MergedUsr
> However, there are proposed solutions under development that in terms of
> being favored in a consensus discussion are preferable to
> usr-merge-via-symlink farms:
>
> A) An extraordinary upgrade process. For example requiring that if you
> are running on a system that is not usrmerged already, you need to
> install usrmerge at the beginning of the upgrade.
> (it could still be transitively essential, but explicitly asking people
> where it matters to install early).
>
> b) Require that bookworm packages work on non-usrmerged systems and
> support non-usrmerged build chroots in the bookworm cycle.
>
> None of these solutions are ideal.
> There is still technical work to do, and there a absolutely are open
> technical issues.
Agreed. And if the folks who are working can let us know how we can
help determine how we can come to some kind of resolution on those
open technical issues, that would be great. Letting things drag out
isn't going to be helpful, so once we have mature options to consider,
hopefully we can weigh the pros and the cons and come to some kind of
group "hum" about the best path forward.
(And I'm having flashbacks to my days as an IETF working group chair. :-)
- Ted
[toc] | [prev] | [next] | [standalone]
| From | Simon Richter <sjr@debian.org> |
|---|---|
| Date | 2021-08-20 23:20 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <COk5H-3Gj-7@gated-at.bofh.it> |
| In reply to | #101204 |
[Multipart message — attachments visible in raw view] — view raw
Hi,
On 8/20/21 3:56 PM, Sam Hartman wrote:
> Simon's position seemed to be that we need a dpkg update in order to
> move forward and that we cannot depend on that mid-release.
Yes, except if we give up "apt dist-upgrade" as the interface for the
upgrade to the next stable release.
> I can see two arguments why we might need a dpkg update:
>
> 1) To fix bugs related to directory aliasing.
>
> I don't think that there is a consensus those bugs need to be fixed to
> move forward. (Put another way it's not clear the community agrees they
> are RC).
dpkg as it is now will detect only the case when a file is moved to the
usrmerge path inside a package, or when a file is moved from one package
to another (with Replaces), but not both at the same time.
So when I build a test package
Package: test1
Version: 1
Architecture: all
Maintainer: foo
Description: foo
containing
./lib
./lib/test
and a second package
Package: test2
Version: 1
Architecture: all
Replaces: test1 (= 1)
Maintainer: foo
Description: foo
containing
./usr
./usr/lib
./usr/lib/test
and I install both, then dpkg will have test1 registered as the owner of
/lib/test and test2 as the owner of /usr/lib/test. Uninstalling test1
then deletes /lib/test, so /usr/lib/test is also gone.
We can work around that by introducing a policy that no files that are
currently registered as living outside /usr may be moved between
packages, but... just no.
Good thing /usr/bin/which doesn't need to be moved from /bin, or we'd
have our first counterexample already. :/
The current dpkg is also unusable for symlink farming, so I will have to
retract my earlier statement about that being a viable transition
method: it is not.
Package: test
Version: 1
Architecture: all
Maintainer: foo
Description: foo
containing
./lib
./usr
./usr/lib
./usr/lib/test
./lib/test -> ../usr/lib/test
fails to unpack on usrmerged systems with
unable to open '/usr/lib/test.dpkg-new': No such file or directory
This is the version of dpkg that will handle the beginning of the "apt
dist-upgrade" process for bullseye->bookworm updates, and the point at
which dpkg itself will be upgraded is determined by the current version
of apt, so our hands are kind of tied here.
> IN particular, most systems are usrmerged today, and while these bugs
> are annoying, many people get along just fine.
Yes, and on all of these systems, dpkg does not have an accurate view of
what is installed, so an upgrade to bookworm that moves files between
packages is likely to have files vanish, depending on the order in which
packages are installed.
> Yes, there are bugs.
> Yes, it would be good to get them fixed in the bookworm cycle.
> But despite the issue being brought up, there is not strong support for
> the idea that we must block on a solution to the dpkg directory aliasing
> bugs.
I think that one of the release goals should be that any freshly
installed or upgraded system should have a dpkg database that is
consistent with reality, and I'd prioritize that higher than actually
finishing the transition, because as long as we can have files vanish
from under us, we can't expect that the transition will be reliable for
bullseye->bookworm updates.
Basically, we've been lucky so far.
> 2)
> We might need a dpkg update to actually do the transition.
Yes, that was my symlink farmer idea, but that doesn't work:
special-case replacing a directory that only contains symlinks with a
symlink, the same way GNU Stow tries to create its symlinks on the
highest possible level, but since dpkg refuses to even unpack a package
that contains a compatibility symlink and the file itself on an
usrmerged system, this won't work.
Since we need a mechanism to clean up the mess the usrmerge package left
us with, adding this mechanism to dpkg itself might still be a good idea
-- while that isn't the first package to be upgraded, it is among the
first, so we can create a safe environment for later packages and thus
minimize the number of packages we have to leave in "reinstreq" state.
Simon
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2021-08-21 15:40 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <COzo6-4Ff-13@gated-at.bofh.it> |
| In reply to | #101225 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, 2021-08-20 at 23:15 +0200, Simon Richter wrote: > Hi, > > On 8/20/21 3:56 PM, Sam Hartman wrote: > > > Simon's position seemed to be that we need a dpkg update in order > > to > > move forward and that we cannot depend on that mid-release. > > Yes, except if we give up "apt dist-upgrade" as the interface for the > upgrade to the next stable release. Forgive me, but you have made this statement a few times now, and each time you have been asked for a reference to what usrmerge-specific measures were adopted in Ubuntu's distro updater to justify it, but so far I have not seen any (I might have simply missed it, in which case I apologize in advance). Could you please share such reference(s) so that we can understand what you are referring to? > > I can see two arguments why we might need a dpkg update: > > > > 1) To fix bugs related to directory aliasing. > > > > I don't think that there is a consensus those bugs need to be fixed > > to > > move forward. (Put another way it's not clear the community agrees > > they > > are RC). > > dpkg as it is now will detect only the case when a file is moved to > the > usrmerge path inside a package, or when a file is moved from one > package > to another (with Replaces), but not both at the same time. Your example is essentially having /bin/foo and /usr/bin/foo at the same time, while not being bit-by-bit identical. I was under the impression that this was already considered RC-buggy and has been for a long while? Am I mistaken and is that not the case? If so, how common is it in the archive, do we have numbers? > > IN particular, most systems are usrmerged today, and while these > > bugs > > are annoying, many people get along just fine. > > Yes, and on all of these systems, dpkg does not have an accurate view > of > what is installed, so an upgrade to bookworm that moves files between > packages is likely to have files vanish, depending on the order in > which > packages are installed. Why has this not happened upgrading from Buster to Bullseye? Or 19.10 to 20.04? Or 20.04 to 20.10? Etc. What's different in Bookworm that would cause these issues to suddenly appear? > > Yes, there are bugs. > > Yes, it would be good to get them fixed in the bookworm cycle. > > But despite the issue being brought up, there is not strong support > > for > > the idea that we must block on a solution to the dpkg directory > > aliasing > > bugs. > > I think that one of the release goals should be that any freshly > installed or upgraded system should have a dpkg database that is > consistent with reality, and I'd prioritize that higher than actually > finishing the transition, because as long as we can have files vanish > from under us, we can't expect that the transition will be reliable > for > bullseye->bookworm updates. > > Basically, we've been lucky so far. Sorry but I for one strongly disagree that this should be a release goal at all. It's an internal implementation detail caused by a 20 years old bug in dpkg - the maintainers of which are free to fix such bug at any time if they like (as they were in the past 20 years since this has been open and remained unaddressed), or to keep ignoring it. What is very relevant is which real consequences this does bring to the surface for users, and so far the only proven, reported and unsolved issue I have seen is the dpkg -S inconvenience, despite multiple years and an install base approaching 100% of a very popular distro like Ubuntu - of course, it is entirely possible that I simply missed them, in which case links to relevant Launchpad/bugs.d.o would be more than welcome. > > 2) > > We might need a dpkg update to actually do the transition. > > Yes, that was my symlink farmer idea, but that doesn't work: > special-case replacing a directory that only contains symlinks with a > symlink, the same way GNU Stow tries to create its symlinks on the > highest possible level, but since dpkg refuses to even unpack a > package > that contains a compatibility symlink and the file itself on an > usrmerged system, this won't work. > > Since we need a mechanism to clean up the mess the usrmerge package > left > us with, adding this mechanism to dpkg itself might still be a good > idea > -- while that isn't the first package to be upgraded, it is among the > first, so we can create a safe environment for later packages and > thus > minimize the number of packages we have to leave in "reinstreq" > state. > > Simon Sorry, but so far it is not proven at all that we _need_ to clean up anything. Some people would very strongly like to do so, and that's a fine and legitimate opinion to hold. But it is factual that it is not objectively _needed_, otherwise Ubuntu wouldn't ship and default-usr- merged Debian installations since Buster wouldn't exist, and older-and- migrated-via-usrmerge installations since Buster wouldn't exist either. -- Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Sam Hartman <hartmans@suchdamage.org> |
|---|---|
| Date | 2021-08-23 16:40 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CPjhg-87Y-17@gated-at.bofh.it> |
| In reply to | #101225 |
[Multipart message — attachments visible in raw view] — view raw
>>>>> "Simon" == Simon Richter <sjr@debian.org> writes:
>> I can see two arguments why we might need a dpkg update:
>>
>> 1) To fix bugs related to directory aliasing.
>>
>> I don't think that there is a consensus those bugs need to be
>> fixed to move forward. (Put another way it's not clear the
>> community agrees they are RC).
Simon> dpkg as it is now will detect only the case when a file is
Simon> moved to the usrmerge path inside a package, or when a file
Simon> is moved from one package to another (with Replaces), but not
Simon> both at the same time.
I confirm I do not consider this RC nor do I believe it should block the
transition.
[explanation removed from quoted material]
Simon> We can work around that by introducing a policy that no files
Simon> that are currently registered as living outside /usr may be
Simon> moved between packages, but... just no.
When combined with a policy that you should not move files from
/bin|/lib to /usr/bin|/usr/lib in the bookworm cycle, that seems
workable to me.
In other words, individual packages should not transition to usrmerged
paths on their own during this cycle.
There may be some corner case where we need this.
If so, we'll have to consider the replaces issues.
Presumably we could replace and explicitly conflict rather than
breaking.
And yes that's not ideal but it will be sufficient to make sure that
both packages are not unpacked at the same time.
>> Yes, there are bugs. Yes, it would be good to get them fixed in
>> the bookworm cycle. But despite the issue being brought up,
>> there is not strong support for the idea that we must block on a
>> solution to the dpkg directory aliasing bugs.
Simon> I think that one of the release goals should be that any
Simon> freshly installed or upgraded system should have a dpkg
Simon> database that is consistent with reality, and I'd prioritize
Simon> that higher than actually finishing the transition, because
Simon> as long as we can have files vanish from under us, we can't
Simon> expect that the transition will be reliable for
bullseye-> bookworm updates.
I think you are in the rough (not part of the consensus) on this desire.
[toc] | [prev] | [next] | [standalone]
| From | Aurelien Jarno <aurelien@aurel32.net> |
|---|---|
| Date | 2021-08-25 21:40 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CQ6UF-5AF-1@gated-at.bofh.it> |
| In reply to | #101225 |
[Multipart message — attachments visible in raw view] — view raw
On 2021-08-20 23:15, Simon Richter wrote: > I think that one of the release goals should be that any freshly installed > or upgraded system should have a dpkg database that is consistent with > reality, and I'd prioritize that higher than actually finishing the > transition, because as long as we can have files vanish from under us, we > can't expect that the transition will be reliable for bullseye->bookworm > updates. > > Basically, we've been lucky so far. I am not sure we have been so lucky. Problems have been found during the release cycles, some of them got fixed (#953562), some other are still there (#926699). -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net
[toc] | [prev] | [next] | [standalone]
| From | Danilo Santos <santosdanilo2013@gmail.com> |
|---|---|
| Date | 2021-08-26 08:20 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CQgU1-3WG-1@gated-at.bofh.it> |
| In reply to | #101377 |
[Multipart message — attachments visible in raw view] — view raw
Today's update, Debian test can't read my windows partition. I fix it inside the bios configuration. El mié, 25 de ago. de 2021 a la(s) 15:27, Aurelien Jarno ( aurelien@aurel32.net) escribió: > On 2021-08-20 23:15, Simon Richter wrote: > > I think that one of the release goals should be that any freshly > installed > > or upgraded system should have a dpkg database that is consistent with > > reality, and I'd prioritize that higher than actually finishing the > > transition, because as long as we can have files vanish from under us, we > > can't expect that the transition will be reliable for bullseye->bookworm > > updates. > > > > Basically, we've been lucky so far. > > I am not sure we have been so lucky. Problems have been found during the > release cycles, some of them got fixed (#953562), some other are still > there (#926699). > > -- > Aurelien Jarno GPG: 4096R/1DDD8C9B > aurelien@aurel32.net http://www.aurel32.net > -- *Grupo Santos Frias S.R.L* *Danilo Alejandro Santos Frias* *Cel: (809) 708-7460*
[toc] | [prev] | [next] | [standalone]
Page 8 of 13 — ← Prev page 1 … 6 7 [8] 9 10 … 13 Next page →
Back to top | Article view | linux.debian.devel
csiph-web