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 6 of 13 — ← Prev page 1 … 4 5 [6] 7 8 … 13 Next page →
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2021-08-21 15:50 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <COzxL-4IF-3@gated-at.bofh.it> |
| In reply to | #101238 |
[Multipart message — attachments visible in raw view] — view raw
On Sat, 2021-08-21 at 10:26 +0200, Wouter Verhelst wrote: > On Fri, Aug 20, 2021 at 11:21:55AM +0100, Luca Boccassi wrote: > > On Thu, 2021-08-19 at 19:55 -0400, Theodore Ts'o wrote: > > > On Thu, Aug 19, 2021 at 10:39:45PM +0200, Simon Richter wrote: > > > > > > > > I think no one likes that idea, but it's the only solution that > > > > doesn't > > > > immediately fail because it requires a dpkg update that hasn't > > > > shipped with > > > > the current stable release, breaks local packages (kernel > > > > modules, firmware, > > > > site-wide systemd configuration), or both. > > > > > > This could be solved if we could somehow require dpkg to be > > > updated > > > before any other packages during the the next update, no? > > > > > > Breaking this constraint means that we can't make "apt-get > > > dist-update" work seemlessly --- but what if we were to change > > > the > > > documented procedure for doing a major update? > > > > > > That's not ideal, granted, but how does that compare against the > > > other > > > alternatives? > > > > > > - Ted > > > > > > P.S. I had a vague memory that there was some update in the long > > > distant past where we did require a manual upgrade of dpkg > > > first. Or > > > is my memory playing tricks on me? I do know that a manual > > > update of > > > dpkg is the first step in a crossgrade.... > > > > An update to dpkg is not _required_. It might be very strongly > > _desired_ which is a perfectly legitimate stance to take, but it is > > not > > technically required, otherwise we couldn't have been shipping with > > merged-usr as default in new installations of Buster and Bullseye > > for > > 2+ years, we could not have been installing usrmerge in older > > installations for 2+ years, and Ubuntu would not exist anymore > > since > > legacy split-usr is discontinued and even older installations are > > being > > forcibly converted. So continuing to live with this minor ~20 years > > old > > dpkg bug as we've been doing for years is a valid option - one that > > some might very, very strongly dislike and argue against which is > > again > > perfectly legitimate, but it is de-facto an option nonetheless, > > because > > it's the actual status quo for 2+ years. > > It bothers me that you believe "we've been doing this for a while and > it > didn't cause any problems, so let's just continue doing things that > way > even if the people who actually wrote the damn code say that path is > littered with minefields and they're scared of what could happen when > we > finish the tranition this way" is a valid strategy. It goes against > everything I was taught to do to write reliable software. Many people are bothered by many things - such is life. For example, I am very bothered that it appears impossible to do any kind of project- wide innovation in Debian, and that we have been delegating that to other distros since forever, and seem condemned to, at best, frantically play catch-up, and at worst be dragged, kicking and screaming, into what has been normal everywhere else for a decade, by upstreams tired and frustrated of having to maintain legacy code paths for the sole and exclusive benefit of this project. But I digress. The main point is that of course the insights of experts are extremely important, incredibly valuable and worth careful consideration, especially when making decisions about an unknown future and events yet to unfold. But in this case these are predictions about the past, a past that already exists and is lived experience for many users here, and for all users in Ubuntu. So there need to be _very_ convincing explanations on why these predictions do not seem to match reality at all, and so far these explanations have failed to materialize, I'm afraid. We have been told everything is broken and the sky is about to fall any minute now, and yet we have not been inundated with new bugs since Buster made merged-usr the default, we have not been inundated with new bugs by users upgrading from Buster to Bullseye or installing usrmerge (despite the yet unsubstantiated claim in this thread that apt dist-upgrade would stop working and require abandoning as a way to upgrade the distro), and Canonical is not drowning in bug reports for making usrmerge the mandated reality of 100% of its user base. The usrmerge Launchpad has 2 (two) bugs [1]. The usrmerge Debian page has 4 (four) bugs, two of which are feature requests [2]. This is hardly the stuff of nightmares. If one's expert viewpoints and predictions do not match reality, they are not entitled to gloss over it because they are the recognized and widely appreciated foremost expert in the field. The reality of this industry is that reliable software is an oxymoron: the only bug-free software is the one that doesn't exist. So the question becomes, what is the measurable impact and magnitude of known bugs and what is the likelihood and projected appearance rate of unknown bugs given measured history. The objective answer for this case is that the known, measured, unsolved and user-visible impact is having to sometimes type 'dpkg -S' again, adding/removing a 4 characters suffix. I can only dream that all the software projects I work on could have something of this magnitude as the actual worst-severity reported bug, as my stress and burnout levels would drastically plummet. -- Kind regards, Luca Boccassi [1] https://bugs.launchpad.net/ubuntu/+source/usrmerge [2] https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=usrmerge
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <wouter@debian.org> |
|---|---|
| Date | 2021-08-21 16:30 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <COAat-5gm-1@gated-at.bofh.it> |
| In reply to | #101255 |
On Sat, Aug 21, 2021 at 02:40:02PM +0100, Luca Boccassi wrote:
> On Sat, 2021-08-21 at 10:26 +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.
>
> Many people are bothered by many things - such is life. For example, I
> am very bothered that it appears impossible to do any kind of project-
> wide innovation in Debian,
"I don't deny the benefits. I do think that in the current
implementation, the drawbacks outweigh those benefits. That's not to
say it couldn't be done. But if it is done, we should do it *right*.
We're Debian. That's what we do."
-- Colin Walters, https://lists.debian.org/debian-devel/2003/06/msg00475.html
It's true that there are other distributions out there who go for the
quick-and-dirty solution, who want the feature before the benefits,
downsides, and risks have all been fleshed out. There's a reason why I'm
not contributing to those distributions; there's a reason why I don't
use those distributions.
"Doing it right", even if that takes time, has proven benefits.
When the RPM world implemented "multiarch", they only supported
installing 32-bit binaries on 64-bit versions of the same architecture.
They did have that feature implemented and functioning in a few months
or so, but the functionality of it was very limited -- and even today it
has problems, in that the way in which RPM checks that packages are
correct has some inherent heuristics that can make mistakes. Yes, I've
encountered those in practice on CentOS systems that my customers at the
time really really wanted to get up and running again pretty quickly.
When Debian and Ubuntu implemented multiarch (look ma, no quotes), the
time from concept to tests to implementation to public availability was
*much* longer than it was in the RPM world; and while this work was
unfinished, there was a lot of angry nagging about the lack of this
feature and why can they do it in the RPM world you guys are idiots, but
eventually it was implemented; and I think you'll agree that the dpkg
implementation of multiarch is far superior to the RPM one: it's
possible to use multiarch not just for compatibility with 32-bit
versions of your 64-bit platform, as in the RPM world, but *also* for
running arm binaries on x86 with qemu user emulation, or for
cross-compiling, or for various other features that the RPM world can
only dream of.
To get back to the point: I'm not saying we shouldn't merge /usr. We
should; the benefits of a properly merged /usr far outweigh any
disadvantages it may bring. However, having an inconsistent dpkg
database is far more serious than just "oh dpkg -S won't work as
expected". It means dpkg isn't properly keeping track of which files
belong to which package anymore, which means you will have issues with a
package that Replaces: another, or with removing packages (especially
with security-conscious binaries), or with diversions, or with
alternatives, or with file conflicts, or with basically anything that
asks dpkg about locations of files; and just dismissing it with a
handwavy "ah well just run dpkg -S again" is so far removed from reality
that it's not even funny. I think the dpkg maintainers are 100% correct
to point out that that *is* a problem for which currently no viable
solution seems to exist, and that any way forward *must* include a
solution to that problem.
I'm not saying the solution which the dpkg maintainers are proposing is
the only valid solution, but if you go and tell them "ah the real
problems you point out are irrelevant" then You! Are! Doing! It! Wrong!
[...]
> The main point is that of course the insights of experts are extremely
> important, incredibly valuable and worth careful consideration,
> especially when making decisions about an unknown future and events yet
> to unfold. But in this case these are predictions about the past, a
> past that already exists and is lived experience for many users here,
> and for all users in Ubuntu.
What that is, is anecdotal evidence. "We've been doing X for a while and
it seems to not kill everything". Cool, great, awesome data points, but
not likely to convince me that there won't ever be any problems. You
can't prove the absense of bugs by anecdotal evidence; you can only
prove the existence of them that way.
What the dpkg maintainers are providing is analytical evidence. "There's
some corner cases here which need to be catered to". You just can't say
that corner cases don't happen because "anecdotal evidence". That's just
not how any of that works.
[...]
> The reality of this industry is that reliable software is an oxymoron:
> the only bug-free software is the one that doesn't exist.
I said "reliable", not "bug-free". It's impossible to write bug-free
software, I think we can agree on that.
However, going all hand-wavy about problems pointed out by people who
know the code intimately is not likely to improve the reliability of the
resulting system.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2021-08-21 19:50 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CODi1-784-1@gated-at.bofh.it> |
| In reply to | #101256 |
[Multipart message — attachments visible in raw view] — view raw
On Sat, 2021-08-21 at 16:20 +0200, Wouter Verhelst wrote: > On Sat, Aug 21, 2021 at 02:40:02PM +0100, Luca Boccassi wrote: > > On Sat, 2021-08-21 at 10:26 +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. > > > > Many people are bothered by many things - such is life. For > > example, I > > am very bothered that it appears impossible to do any kind of > > project- > > wide innovation in Debian, > > "I don't deny the benefits. I do think that in the current > implementation, the drawbacks outweigh those benefits. That's not > to > say it couldn't be done. But if it is done, we should do it > *right*. > We're Debian. That's what we do." > > -- Colin Walters, > https://lists.debian.org/debian-devel/2003/06/msg00475.html > > It's true that there are other distributions out there who go for the > quick-and-dirty solution, who want the feature before the benefits, > downsides, and risks have all been fleshed out. There's a reason why > I'm > not contributing to those distributions; there's a reason why I don't > use those distributions. > > "Doing it right", even if that takes time, has proven benefits. > > When the RPM world implemented "multiarch", they only supported > installing 32-bit binaries on 64-bit versions of the same > architecture. > They did have that feature implemented and functioning in a few > months > or so, but the functionality of it was very limited -- and even today > it > has problems, in that the way in which RPM checks that packages are > correct has some inherent heuristics that can make mistakes. Yes, > I've > encountered those in practice on CentOS systems that my customers at > the > time really really wanted to get up and running again pretty quickly. > > When Debian and Ubuntu implemented multiarch (look ma, no quotes), > the > time from concept to tests to implementation to public availability > was > *much* longer than it was in the RPM world; and while this work was > unfinished, there was a lot of angry nagging about the lack of this > feature and why can they do it in the RPM world you guys are idiots, > but > eventually it was implemented; and I think you'll agree that the dpkg > implementation of multiarch is far superior to the RPM one: it's > possible to use multiarch not just for compatibility with 32-bit > versions of your 64-bit platform, as in the RPM world, but *also* for > running arm binaries on x86 with qemu user emulation, or for > cross-compiling, or for various other features that the RPM world can > only dream of. My recollection (which might be wrong, but a quick look at release notes seems to support it with 11.04 having multiarch 2 years before Wheezy) is that Canonical led the way with the multiarch effort in Ubuntu, and Debian followed with lots of huffing, puffing and grumbling. > To get back to the point: I'm not saying we shouldn't merge /usr. We > should; the benefits of a properly merged /usr far outweigh any > disadvantages it may bring. However, having an inconsistent dpkg > database is far more serious than just "oh dpkg -S won't work as > expected". It means dpkg isn't properly keeping track of which files > belong to which package anymore, which means you will have issues > with a > package that Replaces: another, or with removing packages (especially > with security-conscious binaries), or with diversions, or with > alternatives, or with file conflicts, or with basically anything that > asks dpkg about locations of files; and just dismissing it with a > handwavy "ah well just run dpkg -S again" is so far removed from > reality > that it's not even funny. I think the dpkg maintainers are 100% > correct > to point out that that *is* a problem for which currently no viable > solution seems to exist, and that any way forward *must* include a > solution to that problem. > > I'm not saying the solution which the dpkg maintainers are proposing > is > the only valid solution, but if you go and tell them "ah the real > problems you point out are irrelevant" then You! Are! Doing! It! > Wrong! Again, if the magnitude of this dpkg bug was really that serious there would be visible consequences after almost 3 years of deployments across two distributions with who knows how many million instances, and yet "having to run dpkg -S again" is all we can see. Where are the bug reports? Where are the enraged users with unusable broken system and lost data? Where are the reports of Canonical going out of business because Ubuntu is unusable? The bug is real, nobody doubts that - it has been filed on dpkg 20 years ago. What I am taking issues with is the representation of its actual, real effects, and thus its severity and the consequences for the project. There are a lot of words being spent on how terrible and broken and unacceptable the status quo is, and yet not a single link to a bug report. By all means, go and fix it, make it a top priority for dpkg to sort out, all hands on deck, whatever needed - but to demand the entire project has to stand still, and to de-facto derail the effort put in to catch up with the rest of the world by imposing an unworkable, demonstrably failed solution (symlinks farm) to work around a dpkg bug instead of fixing it internally, to me does not seem acceptable in any way, shape or form without some real, serious evidence that the sky has indeed fallen. > [...] > > The main point is that of course the insights of experts are > > extremely > > important, incredibly valuable and worth careful consideration, > > especially when making decisions about an unknown future and events > > yet > > to unfold. But in this case these are predictions about the past, a > > past that already exists and is lived experience for many users > > here, > > and for all users in Ubuntu. > > What that is, is anecdotal evidence. "We've been doing X for a while > and > it seems to not kill everything". Cool, great, awesome data points, > but > not likely to convince me that there won't ever be any problems. You > can't prove the absense of bugs by anecdotal evidence; you can only > prove the existence of them that way. > > What the dpkg maintainers are providing is analytical evidence. > "There's > some corner cases here which need to be catered to". You just can't > say > that corner cases don't happen because "anecdotal evidence". That's > just > not how any of that works. "It works for me" is anecdote, bugs count is not, it is a key metric of this industry, I am quite surprised this needs to be specified. It's how we decide whether a release is ready or not. The fact that there is 1 (one) known, encountered and unsolved bug in 2+ years across millions of instances and at least two separate distros is not a one-off anecdote, is high quality hard evidence. What you call analytical evidence on the other hand is a fancy word for "opinion". Opinions are useful and interesting and important, but saying "everything is broken" when there is a surprising lack of evidence of that being the case, is not very useful or constructive. > [...] > > The reality of this industry is that reliable software is an > > oxymoron: > > the only bug-free software is the one that doesn't exist. > > I said "reliable", not "bug-free". It's impossible to write bug-free > software, I think we can agree on that. > > However, going all hand-wavy about problems pointed out by people who > know the code intimately is not likely to improve the reliability of > the > resulting system. There is no bug free software, therefore there is no fully reliable software. But reliability and bug counts are hard metric: how much downtime has this theoretical bug caused, how many broken-beyond-repair deployments, how many users/customers reports, and so on. So the next question then becomes, what is the rate of unreliability introduced by this issue? Three years of evidence suggests very little, of a tiny magnitude. It doesn't mean it doesn't exist, it means severity needs to be appropriate. Let's put it this way: if the dpkg -S root cause was unknown, I _seriously_ doubt the bug report would get a Severity: critical and warrant removal of dpkg (!) or stopping the Bullseye/Bookworm release until it is solved. -- Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Colin Watson <cjwatson@debian.org> |
|---|---|
| Date | 2021-08-21 21:50 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <COFaa-8nt-3@gated-at.bofh.it> |
| In reply to | #101259 |
On Sat, Aug 21, 2021 at 06:47:50PM +0100, Luca Boccassi wrote: > My recollection (which might be wrong, but a quick look at release > notes seems to support it with 11.04 having multiarch 2 years before > Wheezy) is that Canonical led the way with the multiarch effort in > Ubuntu, and Debian followed with lots of huffing, puffing and > grumbling. As a Canonical employee who was involved in the multiarch design work at the time, this is a pretty unfair-to-Debian version of history. Yes, some things took a bit longer to get organized on the Debian side for various reasons, but the design and implementation work was done in collaboration with key people in Debian and was definitely better for it; Guillem and Raphaël in particular did a lot of hard work on dpkg and dpkg-dev respectively. (Also, several of us on the Canonical side regarded ourselves as having one foot firmly in each camp; I certainly didn't see it as a confrontational sort of thing where we were having to drag Debian along with us - rather the contrary, there was a lot of enthusiasm in Debian for it.) -- Colin Watson (he/him) [cjwatson@debian.org]
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2021-08-22 12:00 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <COSqJ-8b6-5@gated-at.bofh.it> |
| In reply to | #101260 |
[Multipart message — attachments visible in raw view] — view raw
On Sat, 2021-08-21 at 20:45 +0100, Colin Watson wrote: > On Sat, Aug 21, 2021 at 06:47:50PM +0100, Luca Boccassi wrote: > > My recollection (which might be wrong, but a quick look at release > > notes seems to support it with 11.04 having multiarch 2 years > > before > > Wheezy) is that Canonical led the way with the multiarch effort in > > Ubuntu, and Debian followed with lots of huffing, puffing and > > grumbling. > > As a Canonical employee who was involved in the multiarch design work > at > the time, this is a pretty unfair-to-Debian version of history. Yes, > some things took a bit longer to get organized on the Debian side for > various reasons, but the design and implementation work was done in > collaboration with key people in Debian and was definitely better for > it; Guillem and Raphaël in particular did a lot of hard work on dpkg > and > dpkg-dev respectively. (Also, several of us on the Canonical side > regarded ourselves as having one foot firmly in each camp; I > certainly > didn't see it as a confrontational sort of thing where we were having > to > drag Debian along with us - rather the contrary, there was a lot of > enthusiasm in Debian for it.) So my recollection was indeed wrong - I'll happily retract the comment with apologies, thank you for correcting me. -- Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Guillem Jover <guillem@debian.org> |
|---|---|
| Date | 2021-08-21 23:00 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <COGfT-z1-5@gated-at.bofh.it> |
| In reply to | #101259 |
On Sat, 2021-08-21 at 18:47:50 +0100, Luca Boccassi wrote:
> My recollection (which might be wrong, but a quick look at release
> notes seems to support it with 11.04 having multiarch 2 years before
> Wheezy) is that Canonical led the way with the multiarch effort in
> Ubuntu, and Debian followed with lots of huffing, puffing and
> grumbling.
You mean that time when Ubuntu merged an implementation based on a broken
design with broken interfaces, that was causing dpkg database damage, where
the tech-ctte also tried to force through, in all its wisdom? Right, great
example. (And let's ignore release cadences for more spectacular effect.)
<https://lists.debian.org/debian-devel-announce/2012/03/msg00005.html>
But just wow, such a mischaracterization and deformation of the events.
Sadly, at this point I'm not surprised. This goes along comments such as
that the intersection of packages not using debhelper and shipping
split-/usr files are in the "thousands" (way less than the actual number
of packages shipping those pathnames), or the ones in the paragraphs
below about that mythical bug report, and the single failed attempt to
symlink farm, etc, etc…
> On Sat, 2021-08-21 at 16:20 +0200, Wouter Verhelst wrote:
> > I'm not saying the solution which the dpkg maintainers are proposing
> > is the only valid solution, but if you go and tell them "ah the real
> > problems you point out are irrelevant" then You! Are! Doing! It!
> > Wrong!
>
> Again, if the magnitude of this dpkg bug was really that serious there
> would be visible consequences after almost 3 years of deployments
> across two distributions with who knows how many million instances, and
> yet "having to run dpkg -S again" is all we can see. Where are the bug
> reports? Where are the enraged users with unusable broken system and
> lost data? Where are the reports of Canonical going out of business
> because Ubuntu is unusable?
Just like no one had detected the database corruption in Ubuntu before
I spotted the problem via code review and analysis (which I guess in
your world translates to "opinion"). I'd expect the problems with
aliased directories to be that kind of insidious issue that people
have a very hard time trying to pin point, and which will be getting
worse as time passes.
> The bug is real, nobody doubts that - it has been filed on dpkg 20
> years ago.
You keep repeating this, but I have no idea what bug you refer to.
There's #148258 (from 2002), which is conffile related, and not
actionable and should probably just be closed.
There's #182747 (from 2003), which while apparently similar is
something else completely. This is about the (IMO) misfeature of
supporting a local admin to redirect (not alias) a directory using a
local symlink (mainly for space management reasons). For an explanation
see <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779060#10>.
There's #406715 (from 2007) which is related to the above misfeature.
> What I am taking issues with is the representation of its
> actual, real effects, and thus its severity and the consequences for
> the project. There are a lot of words being spent on how terrible and
> broken and unacceptable the status quo is, and yet not a single link
> to a bug report.
What I'm appalled at is the sloppiness and dogma shown in the name of
a filesystem layout that will have very minimal benefit for final users
(in contrast to some use cases for some admins or installations that
should already know what they are doing, and can manage all potential
downsides in a controlled way through a hack like usrmerge), knowingly
in detriment of robustness and stability.
> By all means, go and fix it, make it a top priority for dpkg to sort
> out, all hands on deck, whatever needed -
To even consider the possibility to support this missing feature in
dpkg would require for it to get support for at least tracking
filesystem metadata (which is has *never* *ever* supported), which is
currently not deployable:
<https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking>
Even with that support in place, that just would not give automatic
aliased directory support. It would need no package to ship anything
inside those directories, and it would also need for some package to
ship those aliased symlinks. And then many corner cases would need to
be considered as then dpkg will need to reconcile what's on the
filesystem, on its database and on the various .deb (given that these
have been a shared resource, that it cannot possibly and safely switch
type by itself), w/o also breaking previous expectations. Not to mention
that the general aliasing issues still would not disappear.
> but to demand the entire project has to stand still,
So wait, when it suits you the "entire project" is involved and cannot
do stuff, but when it does not the "entire project" is not required to
do anything because the proposed solution magically solves stuff for
free with no effort involved… right.
> and to de-facto derail the effort put in to catch up with the rest
> of the world
This again. The rest of the world is not Debian, and as Wouter nicely
put it, we used distinguish ourselves for doing things right. Also while
I'm for merging into /usr, selling it as some kind of technological
advancement breakthrough sounds rather ridiculous. But I guess times
change, and "transitions" now are not planned nor thought nor designed
and people just throw stuff to the wall and just check whether it
sticks or not…
> by imposing an unworkable, demonstrably failed solution (symlinks farm)
So you keep claiming…
> to work around a dpkg bug instead of fixing it internally,
…
> to me does not seem acceptable in any
> way, shape or form without some real, serious evidence that the sky has
> indeed fallen.
If that's an approach to reliable and stable systems where that's
the binary "the sky has fallen" or not, I supposed it follows that
in that world view stuff like security is handled such that an
analysis ("opinion", sorry) of a vulnerability can be downplayed
and ignored because there are no reported botnets riding on.
I guess I might be old fashioned or something, but I'm not interested
at all in sharing such world.
Unimpressed,
Guillem
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2021-08-22 12:30 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <COSTL-8B-5@gated-at.bofh.it> |
| In reply to | #101262 |
[Multipart message — attachments visible in raw view] — view raw
On Sat, 2021-08-21 at 22:57 +0200, Guillem Jover wrote:
> On Sat, 2021-08-21 at 18:47:50 +0100, Luca Boccassi wrote:
> > On Sat, 2021-08-21 at 16:20 +0200, Wouter Verhelst wrote:
> > > I'm not saying the solution which the dpkg maintainers are
> > > proposing
> > > is the only valid solution, but if you go and tell them "ah the
> > > real
> > > problems you point out are irrelevant" then You! Are! Doing! It!
> > > Wrong!
> >
> > Again, if the magnitude of this dpkg bug was really that serious
> > there
> > would be visible consequences after almost 3 years of deployments
> > across two distributions with who knows how many million instances,
> > and
> > yet "having to run dpkg -S again" is all we can see. Where are the
> > bug
> > reports? Where are the enraged users with unusable broken system
> > and
> > lost data? Where are the reports of Canonical going out of business
> > because Ubuntu is unusable?
>
> Just like no one had detected the database corruption in Ubuntu
> before
> I spotted the problem via code review and analysis (which I guess in
> your world translates to "opinion"). I'd expect the problems with
> aliased directories to be that kind of insidious issue that people
> have a very hard time trying to pin point, and which will be getting
> worse as time passes.
If I understand correctly, what has been stated as a potential
theoretical consequence is files disappearing and upgrades failing. Why
would these be hard to detect? It would seem to be a pretty visible
consequence, no?
> > The bug is real, nobody doubts that - it has been filed on dpkg 20
> > years ago.
>
> You keep repeating this, but I have no idea what bug you refer to.
>
> There's #148258 (from 2002), which is conffile related, and not
> actionable and should probably just be closed.
>
> There's #182747 (from 2003), which while apparently similar is
> something else completely. This is about the (IMO) misfeature of
> supporting a local admin to redirect (not alias) a directory using a
> local symlink (mainly for space management reasons). For an
> explanation
> see <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779060#10>.
>
> There's #406715 (from 2007) which is related to the above misfeature.
I am referring to #134758 since it's linked as the root cause from
usrmerge's #848622.
"dpkg-query: Make -S handle unowned symlinks resolving to owned
pathnames" filed in February 2002 - 19 years and a half ago. I refer to
that because it's linked as the root cause in the BTS of the relevant
issue with usrmerge we are discussing.
> > What I am taking issues with is the representation of its
> > actual, real effects, and thus its severity and the consequences
> > for
> > the project. There are a lot of words being spent on how terrible
> > and
> > broken and unacceptable the status quo is, and yet not a single
> > link
> > to a bug report.
>
> What I'm appalled at is the sloppiness and dogma shown in the name of
> a filesystem layout that will have very minimal benefit for final
> users
> (in contrast to some use cases for some admins or installations that
> should already know what they are doing, and can manage all potential
> downsides in a controlled way through a hack like usrmerge),
> knowingly
> in detriment of robustness and stability.
**in your opinion** it will have minimal benefits. It is a legitimate
opinion, but still an opinion with which others disagree. Seeing how
every popular distro has moved or is moving, general consensus appear
to be going in the other direction. On the other hand, robustness and
stability are measurable: number of crashes, number of lost systems,
number of systems with lost data. The total count in the past 3 years
where it has been default in Debian and Ubuntu puts the grand total of
reports of crashes, lost systems and lost data at zero. So again, the
evidence that this change decreases stability is nowhere to be seen.
> > By all means, go and fix it, make it a top priority for dpkg to
> > sort
> > out, all hands on deck, whatever needed -
>
> To even consider the possibility to support this missing feature in
> dpkg would require for it to get support for at least tracking
> filesystem metadata (which is has *never* *ever* supported), which is
> currently not deployable:
>
> <https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking>
>
> Even with that support in place, that just would not give automatic
> aliased directory support. It would need no package to ship anything
> inside those directories, and it would also need for some package to
> ship those aliased symlinks. And then many corner cases would need to
> be considered as then dpkg will need to reconcile what's on the
> filesystem, on its database and on the various .deb (given that these
> have been a shared resource, that it cannot possibly and safely
> switch
> type by itself), w/o also breaking previous expectations. Not to
> mention
> that the general aliasing issues still would not disappear.
I make no claim whatsoever on whether it would be easy, simple or
anything else. Others have proposed solutions, I have not commented on
them nor intend to.
> > but to demand the entire project has to stand still,
>
> So wait, when it suits you the "entire project" is involved and
> cannot
> do stuff, but when it does not the "entire project" is not required
> to
> do anything because the proposed solution magically solves stuff for
> free with no effort involved… right.
It doesn't suit "me" - it "suits" the unanimous decision of the
Technical Committee.
> > and to de-facto derail the effort put in to catch up with the rest
> > of the world
>
> This again. The rest of the world is not Debian, and as Wouter nicely
> put it, we used distinguish ourselves for doing things right. Also
> while
> I'm for merging into /usr, selling it as some kind of technological
> advancement breakthrough sounds rather ridiculous. But I guess times
> change, and "transitions" now are not planned nor thought nor
> designed
> and people just throw stuff to the wall and just check whether it
> sticks or not…
Nobody is selling this as a breakthrough, it was never claimed to be, I
don't see how such hyperboles help anybody. Quite the opposite, while
ten years ago it might have been a nice idea to simplify things
considerably, today is just a boring standard behaviour in most places
- nothing extraordinary about it. It is relevant for its absence, if
anything, as it pushes upstreams to keep legacy stuff around, which is
getting tiresome.
> > by imposing an unworkable, demonstrably failed solution (symlinks
> > farm)
>
> So you keep claiming…
It is not a claim, it's an observation. A distro with much better tools
and a very strong governance model tried it and failed for reasons
explained a million times already (and always invariably ignored by you
and a few others). That's solid, hard evidence.
> > to work around a dpkg bug instead of fixing it internally,
>
> …
>
> > to me does not seem acceptable in any
> > way, shape or form without some real, serious evidence that the sky
> > has
> > indeed fallen.
>
> If that's an approach to reliable and stable systems where that's
> the binary "the sky has fallen" or not, I supposed it follows that
> in that world view stuff like security is handled such that an
> analysis ("opinion", sorry) of a vulnerability can be downplayed
> and ignored because there are no reported botnets riding on.
>
> I guess I might be old fashioned or something, but I'm not interested
> at all in sharing such world.
>
> Unimpressed,
> Guillem
No, it doesn't follow as that at all, this is a strawman of your own
creation - as it turns out, different things might be different and be
handled differently. I must say statements like this makes the "assume
good faith" principle incredibly hard to follow. One states that
despite widespread, default usage across multiple distros for years
there's no evidence of unrecoverable failures, and instead of providing
evidence of the contrary or explanations for the absence of such
evidence, the answer is "oh well I guess you ignore security
vulnerabilities then"? How is this a constructive answer?
--
Kind regards,
Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Steve Cotton <steve@octalot.at> |
|---|---|
| Date | 2021-08-22 13:10 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <COTwt-BZ-1@gated-at.bofh.it> |
| In reply to | #101274 |
Am Sun, Aug 22, 2021 at 11:21:38AM +0100 schrieb Luca Boccassi: > On Sat, 2021-08-21 at 22:57 +0200, Guillem Jover wrote: > > Just like no one had detected the database corruption in Ubuntu before > > I spotted the problem via code review and analysis (which I guess in > > your world translates to "opinion"). I'd expect the problems with > > aliased directories to be that kind of insidious issue that people > > have a very hard time trying to pin point, and which will be getting > > worse as time passes. > > If I understand correctly, what has been stated as a potential > theoretical consequence is files disappearing and upgrades failing. Why > would these be hard to detect? It would seem to be a pretty visible > consequence, no? How would you know which package to log a bug on? Would you feel able to log a useful bug report at all, given that all you've detected is that something is losing data from the filesystem? * How do you know it's not a kernel filesystem bug? * How do you know it's not a kernel caching bug? * How do you know it wasn't just a typo by the administrator? * How long ago did it happen anyway, when did you last use this utility? * Could it have been an accidental power-off? * Hardware bug? * Something installed from experimental? Guillem didn't say it was hard to detect, the text you quoted says "very hard time trying to pin point". Steve
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2021-08-22 23:30 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CP3ct-6Ad-1@gated-at.bofh.it> |
| In reply to | #101277 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, 2021-08-22 at 12:42 +0200, Steve Cotton wrote: > Am Sun, Aug 22, 2021 at 11:21:38AM +0100 schrieb Luca Boccassi: > > On Sat, 2021-08-21 at 22:57 +0200, Guillem Jover wrote: > > > Just like no one had detected the database corruption in Ubuntu > > > before > > > I spotted the problem via code review and analysis (which I guess > > > in > > > your world translates to "opinion"). I'd expect the problems with > > > aliased directories to be that kind of insidious issue that > > > people > > > have a very hard time trying to pin point, and which will be > > > getting > > > worse as time passes. > > > > If I understand correctly, what has been stated as a potential > > theoretical consequence is files disappearing and upgrades failing. > > Why > > would these be hard to detect? It would seem to be a pretty visible > > consequence, no? > > How would you know which package to log a bug on? Would you feel able > to log a > useful bug report at all, given that all you've detected is that > something is > losing data from the filesystem? > > * How do you know it's not a kernel filesystem bug? > * How do you know it's not a kernel caching bug? > * How do you know it wasn't just a typo by the administrator? > * How long ago did it happen anyway, when did you last use this > utility? > * Could it have been an accidental power-off? > * Hardware bug? > * Something installed from experimental? > > Guillem didn't say it was hard to detect, the text you quoted says > "very hard > time trying to pin point". > > Steve Of course I can't know for sure, but if an upgrade "lost" a file, I would imagine a user would file a bug against either the kernel (blaming the filesystem) or dpkg (blaming the package manager). That's what I assume I would do in that situation. Failing that, I suppose the fallback is reaching out to the usual support channels - generalist mailing list, irc. Has there been an increase (or any at all) in bug reports about files disappearing on the kernel/dpkg/apt? Has there been an increase (or any at all) of support request about disappeared files on debian-devel or debian-user? I mean, from my experience our users are very vocal when things break badly, even if they don't know exactly where the root cause is - I am used to see bugs filed against src:nvidia-graphics-driver pretty much anytime anything remotely related to "show stuff on screen" goes wrong, if there happens to be an nvidia card in use :-) -- Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Guillem Jover <guillem@debian.org> |
|---|---|
| Date | 2021-11-12 05:00 +0100 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <DivTj-lo-1@gated-at.bofh.it> |
| In reply to | #101274 |
unblock 848622 by 134758 thanks On Sun, 2021-08-22 at 11:21:38 +0100, Luca Boccassi wrote: > On Sat, 2021-08-21 at 22:57 +0200, Guillem Jover wrote: > > On Sat, 2021-08-21 at 18:47:50 +0100, Luca Boccassi wrote: > > > The bug is real, nobody doubts that - it has been filed on dpkg 20 > > > years ago. > > > > You keep repeating this, but I have no idea what bug you refer to. > > > > There's #148258 (from 2002), which is conffile related, and not > > actionable and should probably just be closed. > > > > There's #182747 (from 2003), which while apparently similar is > > something else completely. This is about the (IMO) misfeature of > > supporting a local admin to redirect (not alias) a directory using a > > local symlink (mainly for space management reasons). For an > > explanation > > see <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779060#10>. > > > > There's #406715 (from 2007) which is related to the above misfeature. > > I am referring to #134758 since it's linked as the root cause from > usrmerge's #848622. Well, that's a bogus block then, because that's obviously not the root cause. I see I was CCed when that block was set, I guess I missed it. :/ Fixed it now… > "dpkg-query: Make -S handle unowned symlinks resolving to owned > pathnames" filed in February 2002 - 19 years and a half ago. I refer to > that because it's linked as the root cause in the BTS of the relevant > issue with usrmerge we are discussing. Even if the wishlist from that report got implemented, it would still not fully solve all the problems, where among them «dpkg-query -S» is probably the lesser one, which would not work in the other direction anyway (querying a path under /usr/ known to dpkg as being under /). And then I'm not convinced this should even be implemented at all, as it would introduce behavior differences between literal pathnames and patterns, and making them slower (for the first case) or potentially extremely slower (for the second case), in addition to making the queries dependent on the on-disk layout (so unreliable from the packaging PoV, as it would invent on the spot, pathnames not truly coming from any package nor otherwise known to dpkg). This for a misfeature in dpkg (supporting redirecting symlinks) that allowed the current mess anyway. So I'm inclined to wontfix and close that one. Not looking forward to further interactions… Guillem
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2021-11-12 12:00 +0100 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <DiCrL-4mH-1@gated-at.bofh.it> |
| In reply to | #102372 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, 2021-11-12 at 04:57 +0100, Guillem Jover wrote: > > On Sun, 2021-08-22 at 11:21:38 +0100, Luca Boccassi wrote: > > On Sat, 2021-08-21 at 22:57 +0200, Guillem Jover wrote: > > > On Sat, 2021-08-21 at 18:47:50 +0100, Luca Boccassi wrote: > > > > The bug is real, nobody doubts that - it has been filed on dpkg 20 > > > > years ago. > > > > > > You keep repeating this, but I have no idea what bug you refer to. > > > > > > There's #148258 (from 2002), which is conffile related, and not > > > actionable and should probably just be closed. > > > > > > There's #182747 (from 2003), which while apparently similar is > > > something else completely. This is about the (IMO) misfeature of > > > supporting a local admin to redirect (not alias) a directory using a > > > local symlink (mainly for space management reasons). For an > > > explanation > > > see <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779060#10>. > > > > > > There's #406715 (from 2007) which is related to the above misfeature. > > > > I am referring to #134758 since it's linked as the root cause from > > usrmerge's #848622. > > Well, that's a bogus block then, because that's obviously not the root > cause. I see I was CCed when that block was set, I guess I missed it. > :/ Fixed it now… > > > "dpkg-query: Make -S handle unowned symlinks resolving to owned > > pathnames" filed in February 2002 - 19 years and a half ago. I refer to > > that because it's linked as the root cause in the BTS of the relevant > > issue with usrmerge we are discussing. > > Even if the wishlist from that report got implemented, it would still > not fully solve all the problems, where among them «dpkg-query -S» > is probably the lesser one, which would not work in the other direction > anyway (querying a path under /usr/ known to dpkg as being under /). > > And then I'm not convinced this should even be implemented at all, > as it would introduce behavior differences between literal pathnames > and patterns, and making them slower (for the first case) or potentially > extremely slower (for the second case), in addition to making the queries > dependent on the on-disk layout (so unreliable from the packaging PoV, > as it would invent on the spot, pathnames not truly coming from any > package nor otherwise known to dpkg). > > This for a misfeature in dpkg (supporting redirecting symlinks) that > allowed the current mess anyway. So I'm inclined to wontfix and close > that one. > > > Not looking forward to further interactions… > Guillem Thanks for following up! There are currently 469 open bugs against src:dpkg, it's of course entirely up to you which ones you choose to fix and which one you close+wontfix. As far as workarounds go, this one is really really trivial to deal with, so I personally wouldn't mind at all. Thank you for your work! -- Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Simon Richter <sjr@debian.org> |
|---|---|
| Date | 2021-08-22 02:20 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <COJns-2BA-3@gated-at.bofh.it> |
| In reply to | #101259 |
Hi,
On 21.08.21 19:47, Luca Boccassi wrote:
> By all means, go and fix it, make it a top priority for dpkg to sort
> out, all hands on deck, whatever needed - but to demand the entire
> project has to stand still, and to de-facto derail the effort put in to
> catch up with the rest of the world by imposing an unworkable,
> demonstrably failed solution (symlinks farm) to work around a dpkg bug
> instead of fixing it internally, to me does not seem acceptable in any
> way, shape or form without some real, serious evidence that the sky has
> indeed fallen.
There are two issues here: dpkg not handling certain corner cases, and
the usemerge package modifying the file system, bypassing dpkg.
The latter is what brought us into a situation where it is no longer
safe to move files between packages and between aliased directories in
the same upgrade, and because users will be expected to upgrade in a
single step between stable releases, that means these two types of
changes are mutually exclusive for the entire release cycle.
This happened precisely because people "put in the effort" to implement
this change without coordinating. This thing derailed on its own, and
accusing the people pointing that out of ill will is not going to fix that.
The fact that the sky has not yet fallen is not a reason for inaction,
but instead gives us the breathing room to implement a proper solution
instead of another hack that will add yet another possible upgrade
scenario we have to anticipate in the future.
We already have inconsistent package builds depending on whether a
package was built on a pre- or post-transition autobuilder, with the
exact same packages installed otherwise.
We have no piuparts test coverage for these scenarios, we have no QA
tools to verify that installing the new packages will always lead to
predictable outcomes no matter in which order you install them in --
such tools were never necessary before as dpkg resolves these problems
in a deterministic manner provided its installation database is
consistent with reality.
This is the situation we're in: the millions of systems out there work,
but we cannot guarantee that they will continue to work through the next
update because the QA infrastructure now has massive blind spots. This
is what needs to be fixed before further progress can be made.
If the bookworm upgrade does break systems on upgrade, then the sky will
indeed have fallen, only then it will be too late to do anything about it.
> "It works for me" is anecdote, bugs count is not, it is a key metric of
> this industry, I am quite surprised this needs to be specified. It's
> how we decide whether a release is ready or not.
I see two problems here:
First, we're not the "industry." We're a Free Software movement. The
industry just happens to embrace us at the moment.
Second, I wonder why it doesn't give you pause if a group of senior
software people that uses a particular metric in one instance suddenly
seems to be utterly unaware of its existence in another.
> What you call analytical
> evidence on the other hand is a fancy word for "opinion".
Analytical evidence happens when you read the dpkg source code and the
usrmerge perl script and find a glaring obvious problem in the way they
interact, then construct a simple adversarial example in 11 lines of
text and two dpkg-deb calls and verify that it indeed loses files.
The scenario I posted will apply to any systemd package split between
bullseye and bookworm. If systemd moves unit files to /usr, then it
cannot move these to another package for the entirety of the release, or
risk the units disappearing on upgrade. It also applies to kernel module
and firmware packages, and several core system utilities.
We got lucky with the "which" command as that was in /usr already.
> Opinions are
> useful and interesting and important, but saying "everything is broken"
> when there is a surprising lack of evidence of that being the case, is
> not very useful or constructive.
Absence of evidence is not evidence of absence.
Simon
[toc] | [prev] | [next] | [standalone]
| From | "Theodore Ts'o" <tytso@mit.edu> |
|---|---|
| Date | 2021-08-22 05:20 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <COMbD-4oS-7@gated-at.bofh.it> |
| In reply to | #101266 |
On Sun, Aug 22, 2021 at 02:15:31AM +0200, Simon Richter wrote:
>
> The latter is what brought us into a situation where it is no longer safe to
> move files between packages and between aliased directories in the same
> upgrade, and because users will be expected to upgrade in a single step
> between stable releases, that means these two types of changes are mutually
> exclusive for the entire release cycle.
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? What are other
possible solutions?
- Ted
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2021-08-22 12:30 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <COSTL-8B-3@gated-at.bofh.it> |
| In reply to | #101267 |
[Multipart message — attachments visible in raw view] — view raw
On Sat, 2021-08-21 at 23:10 -0400, Theodore Ts'o wrote:
> On Sun, Aug 22, 2021 at 02:15:31AM +0200, Simon Richter wrote:
> >
> > The latter is what brought us into a situation where it is no
> > longer safe to
> > move files between packages and between aliased directories in the
> > same
> > upgrade, and because users will be expected to upgrade in a single
> > step
> > between stable releases, that means these two types of changes are
> > mutually
> > exclusive for the entire release cycle.
>
> 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? What are other
> possible solutions?
>
> - Ted
I've asked this before - I might be very wrong, but I was under the
impression that having both /bin/foo and /usr/bin/foo (which is the
example mentioned) was already considered RC-buggy and needed fixing?
Is that not the case?
--
Kind regards,
Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2021-08-22 16:50 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <COWXn-2xF-1@gated-at.bofh.it> |
| In reply to | #101273 |
Luca Boccassi <bluca@debian.org> writes:
> I've asked this before - I might be very wrong, but I was under the
> impression that having both /bin/foo and /usr/bin/foo (which is the
> example mentioned) was already considered RC-buggy and needed fixing?
> Is that not the case?
This is already the case. Policy 10.1:
To support merged-/usr systems, packages must not install files in
both /path and /usr/path. For example, a package must not install both
/bin/example and /usr/bin/example.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2021-08-22 23:30 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CP3cu-6Ad-11@gated-at.bofh.it> |
| In reply to | #101280 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, 2021-08-22 at 07:45 -0700, Russ Allbery wrote: > Luca Boccassi <bluca@debian.org> writes: > > > I've asked this before - I might be very wrong, but I was under the > > impression that having both /bin/foo and /usr/bin/foo (which is the > > example mentioned) was already considered RC-buggy and needed > > fixing? > > Is that not the case? > > This is already the case. Policy 10.1: > > To support merged-/usr systems, packages must not install files > in > both /path and /usr/path. For example, a package must not install > both > /bin/example and /usr/bin/example. Thank you - is that intended to mean "the same package", or "any two packages"? Ie, is foo2 allowed to install /bin/foo if foo1 installs /usr/bin/foo or is that RC-buggy too? -- Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2021-08-23 04:20 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CP7J7-13E-1@gated-at.bofh.it> |
| In reply to | #101292 |
Luca Boccassi <bluca@debian.org> writes: > On Sun, 2021-08-22 at 07:45 -0700, Russ Allbery wrote: >> This is already the case. Policy 10.1: >> To support merged-/usr systems, packages must not install files in >> both /path and /usr/path. For example, a package must not install both >> /bin/example and /usr/bin/example. > Thank you - is that intended to mean "the same package", or "any two > packages"? Ie, is foo2 allowed to install /bin/foo if foo1 installs > /usr/bin/foo or is that RC-buggy too? I don't think we have an explicit statement that you can't do this because I'm not sure it's come up, but it's obviously not a safe thing to do (and that was true long before usrmerge was even considered). -- Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2021-08-23 15:50 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CPiuR-7Cm-1@gated-at.bofh.it> |
| In reply to | #101301 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, 2021-08-22 at 19:10 -0700, Russ Allbery wrote: > Luca Boccassi <bluca@debian.org> writes: > > On Sun, 2021-08-22 at 07:45 -0700, Russ Allbery wrote: > > > > This is already the case. Policy 10.1: > > > > To support merged-/usr systems, packages must not install files in > > > both /path and /usr/path. For example, a package must not install both > > > /bin/example and /usr/bin/example. > > > Thank you - is that intended to mean "the same package", or "any two > > packages"? Ie, is foo2 allowed to install /bin/foo if foo1 installs > > /usr/bin/foo or is that RC-buggy too? > > I don't think we have an explicit statement that you can't do this because > I'm not sure it's come up, but it's obviously not a safe thing to do (and > that was true long before usrmerge was even considered). Thank you - it has been brought up in this thread as an example of a valid setup, so if it is not, I think it could be good to be extra clear in the policy? How about the following: To support merged-\ ``/usr`` systems, packages must not install files in both ``/path`` and ``/usr/path``. For example, a package must not install -both ``/bin/example`` and ``/usr/bin/example``. +both ``/bin/example`` and ``/usr/bin/example``. Also, package ``example-b`` +cannot install ``/bin/example`` if package ``example-a`` already installs +``/usr/bin/example``, and viceversa. -- Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2021-08-23 17:30 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CPk3E-c4-13@gated-at.bofh.it> |
| In reply to | #101318 |
Luca Boccassi <bluca@debian.org> writes: > Thank you - it has been brought up in this thread as an example of a > valid setup, so if it is not, I think it could be good to be extra clear > in the policy? How about the following: If we tried to document every random bit of buggy packaging behavior anyone thought of in Policy, Policy would become unwieldy, so I want to verify here that someone really thought having one package containing a file in /bin and another package containing the same file in /usr/bin was was a reasonable thing to do (as opposed to accidental). Are there packages in the archive like this? Or could you point me at the message in the thread that said this was non-buggy? I think I missed it. This seems clearly nonsensical to me even if usrmerge was never on the horizon, since which binary you got would randomly depend on the PATH ordering and the order of /bin vs. /usr/bin in user-set PATHs is not fixed and has never mattered. (It may be that someone has done this *accidentally* and thus created an edge case that the package management system has to cope with, but that's a question of finding buggy packages, which is not something Policy can really help with.) -- Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
| From | Simon Richter <sjr@debian.org> |
|---|---|
| Date | 2021-08-23 22:10 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CPoqB-2XP-3@gated-at.bofh.it> |
| In reply to | #101323 |
Hi,
On 23.08.21 17:23, Russ Allbery wrote:
[one package with /bin/foo, another with /usr/bin/foo]
> This seems clearly nonsensical to me even if usrmerge was never on the
> horizon, since which binary you got would randomly depend on the PATH
> ordering and the order of /bin vs. /usr/bin in user-set PATHs is not fixed
> and has never mattered.
It is less nonsensical because usrmerge exists, since we presumably
don't want to keep the /bin paths in the packages, so at some point we
need to move /bin/foo to /usr/bin/foo inside a package. That is safe
with current dpkg, as dpkg will not delete /bin/foo if it has the same
inode as a just-unpacked file.
We have another kind of common transition: moving files between packages
with a Replaces: relation.
If a package undergoes both transitions in the same release cycle, then
dpkg would indeed see package A containing /bin/foo, and package B with
Replaces: A containing /usr/bin/foo.
And in this case, /bin/foo can be removed after /usr/bin/foo is
unpacked, and then the file vanishes because dpkg did not register the
ownership transfer.
Simon
[toc] | [prev] | [next] | [standalone]
Page 6 of 13 — ← Prev page 1 … 4 5 [6] 7 8 … 13 Next page →
Back to top | Article view | linux.debian.devel
csiph-web