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 7 of 13 — ← Prev page 1 … 5 6 [7] 8 9 … 13 Next page →
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2021-08-23 22:50 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CPp3j-3aW-1@gated-at.bofh.it> |
| In reply to | #101329 |
Simon Richter <sjr@debian.org> writes: > 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. [...] I think this implies that writing something in Policy about this would be premature. The issues you raise are related to something new that is being discussed and would be part of a migration plan to a merged /usr world. The appropriate time to document those details in Policy would be after we agreed on a plan, not now when they're just tentative ideas. Right now, in the absence of such a plan, it's obvious that having two unrelated packages (that do not Conflict) ship a binary with the same name in /bin and /usr/bin is not sensible, yes? (I believe that's the topic under discussion in this thread.) I'm trying to understand if enough people thought this was a sensible, non-buggy thing to do today that it's worthwhile adding something to Policy explicitly saying that it's not. -- Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
| From | Ansgar <ansgar@43-1.org> |
|---|---|
| Date | 2021-08-23 23:20 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CPpwm-3Al-7@gated-at.bofh.it> |
| In reply to | #101331 |
Hi Russ, On Mon, 2021-08-23 at 13:41 -0700, Russ Allbery wrote: > Right now, in the absence of such a plan, it's obvious that having > two > unrelated packages (that do not Conflict) ship a binary with the same > name > in /bin and /usr/bin is not sensible, yes? (I believe that's the > topic > under discussion in this thread.) I'm trying to understand if enough > people thought this was a sensible, non-buggy thing to do today that > it's > worthwhile adding something to Policy explicitly saying that it's > not. Different, non-conflicting packages shipping binaries with the same name in /bin and /usr/bin (or similar) should be resolved for a while now. That as looked at when usrmerge was first introduced. I'm aware of one instance where this was intentional to prefer one program over the other (molly-guard), but it since uses diversions. (Actually molly-guard ships several /sbin/pm-* binaries, while pm-utils ships them as /usr/sbin/pm-*, but I think this is fine as the ones in pm-utils are diverted by molly-guard's preinst script.) For what it is worth I could find the following instances in Debian bookworm (amd64 + all), not taking into account package conflicts, covering /bin, /sbin and /lib*: sbin/pm-hibernate: root=admin/molly-guard usr=admin/pm-utils,metapackages/progress-linux-container sbin/pm-suspend: root=admin/molly-guard usr=admin/pm-utils,metapackages/progress-linux-container sbin/pm-suspend-hybrid: root=admin/molly-guard usr=admin/pm-utils,metapackages/progress-linux-container sbin/syslogd: root=utils/busybox-syslogd usr=net/inetutils-syslogd bin/systemctl: root=admin/systemd usr=admin/systemctl sbin/update-service: root=admin/runit usr=admin/daemontools-run lib/x86_64-linux-gnu/libsystemd.so.0: root=libs/libelogind0 usr=libs/libsystemd0 sbin/exfatlabel: root=otherosfs/exfat-utils usr=otherosfs/exfatprogs sbin/fsck.exfat: root=otherosfs/exfat-utils usr=otherosfs/exfatprogs sbin/mkfs.exfat: root=otherosfs/exfat-utils usr=otherosfs/exfatprogs And one additional instance in unstable: lib/systemd/system/ifup@.service: root=admin/ifupdown2 usr=admin/ifupdown lib/systemd/system/networking.service: root=admin/ifupdown2 usr=admin/ifupdown Ansgar
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2021-08-23 23:30 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CPpG2-3DA-11@gated-at.bofh.it> |
| In reply to | #101332 |
Ansgar <ansgar@43-1.org> writes: > Different, non-conflicting packages shipping binaries with the same name > in /bin and /usr/bin (or similar) should be resolved for a while > now. That as looked at when usrmerge was first introduced. I'm aware of > one instance where this was intentional to prefer one program over the > other (molly-guard), but it since uses diversions. > (Actually molly-guard ships several /sbin/pm-* binaries, while pm-utils > ships them as /usr/sbin/pm-*, but I think this is fine as the ones in > pm-utils are diverted by molly-guard's preinst script.) > For what it is worth I could find the following instances in Debian > bookworm (amd64 + all), not taking into account package conflicts, > covering /bin, /sbin and /lib*: Thanks for the data! > sbin/pm-hibernate: root=admin/molly-guard usr=admin/pm-utils,metapackages/progress-linux-container > sbin/pm-suspend: root=admin/molly-guard usr=admin/pm-utils,metapackages/progress-linux-container > sbin/pm-suspend-hybrid: root=admin/molly-guard usr=admin/pm-utils,metapackages/progress-linux-container I will assume this uses diversions, but probably the strongest argument for saying something in Policy was this confusion. At least one Debian maintainer didn't realize that diversions were the best way of doing this rather than shipping binaries in a different PATH. > sbin/syslogd: root=utils/busybox-syslogd usr=net/inetutils-syslogd > bin/systemctl: root=admin/systemd usr=admin/systemctl > sbin/update-service: root=admin/runit usr=admin/daemontools-run > lib/x86_64-linux-gnu/libsystemd.so.0: root=libs/libelogind0 usr=libs/libsystemd0 > sbin/exfatlabel: root=otherosfs/exfat-utils usr=otherosfs/exfatprogs > sbin/fsck.exfat: root=otherosfs/exfat-utils usr=otherosfs/exfatprogs > sbin/mkfs.exfat: root=otherosfs/exfat-utils usr=otherosfs/exfatprogs > And one additional instance in unstable: > lib/systemd/system/ifup@.service: root=admin/ifupdown2 usr=admin/ifupdown > lib/systemd/system/networking.service: root=admin/ifupdown2 usr=admin/ifupdown I've chcked these and they all declare explicit Conflicts. -- Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
| From | Sam Hartman <hartmans@debian.org> |
|---|---|
| Date | 2021-08-24 01:30 +0200 |
| Subject | Debhelper and /lib/systemd vs /usr/lib/systemd |
| Message-ID | <CPry9-4LI-1@gated-at.bofh.it> |
| In reply to | #101331 |
[Multipart message — attachments visible in raw view] — view raw
TL;DR: Should we hold off on moving stuff from / to /usr in packages
until we develop our plan?
If so, how do we communicate that to people?
>>>>> "Russ" == Russ Allbery <rra@debian.org> writes:
Russ> Simon Richter <sjr@debian.org> writes:
>> 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.
Russ> [...]
Russ> I think this implies that writing something in Policy about
Russ> this would be premature. The issues you raise are related to
Russ> something new that is being discussed and would be part of a
Russ> migration plan to a merged /usr world.
Russ, I agree with you that it's premature to document this in policy.
However, Simon has raised what I think is a credible argument that it
is harmful to perform both / -> /usr transitions and to move files
between packages in the same release.
My take away from that is that it may be harmful to move a bunch of
stuff from / -> /usr until we have a plan, and that maintainers should
actively be discouraged from doing so.
I think we should get people to hold off at least until we have a
consensus on that point.
And this is by no means theoretical.
As was discussed here, recent debhelper (has or at least had) changed
from installing systemd units in /lib/systemd/system to
/usr/lib/systemd/system.
That is totally fine interms of usermerged stuff, but sets up a
potential problem .
Suppose we have a program foo that ships a daemon and also a systemd
unit to run it.
Later we discover that foo is kind of useful in desktop situations and
other situations where it wants to be started as needed and possibly
not even by systemd.
So, we want to split out the foo package into foo containing the daemon
binary and foo-system (recommended by foo) containing the systemd unit.
The maintainer may not even be thinking about how debhelper moved around
the unit file.
foo-system replaces/breaks the old version of foo.
I think the following series of operations would result in the unit file
disappearing on a usermerged system:
* user has old foo with /lib/systemd/system/foo.service
* user attempts to upgrade and installs foo-system as part of upgrade
* foo is deconfigured because of the breaks on foo-system
* foo-system is unpacked, including
/usr/lib/systemd/system/foo.service. On the usrmerged system, that
overwrites the existing foo.service since dpkg doesn't know about the
aliasing
* foo is upgraded. From dpkg's standpoint it looks like
/lib/systemd/system/foo.service disappeared, but since the file still
exists it is removed.
So the user ends up with no unit.
I think this is particular insidious because the maintainer might not
even know that they had moved files from / to /usr, or if they knew they
might have not been paying enough attention to provide special care.
Do people agree that we want to hold off on this sort of thing until we
get a plan?
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2021-08-24 02:00 +0200 |
| Subject | Re: Debhelper and /lib/systemd vs /usr/lib/systemd |
| Message-ID | <CPs1b-4Vm-1@gated-at.bofh.it> |
| In reply to | #101334 |
Sam Hartman <hartmans@debian.org> writes: > However, Simon has raised what I think is a credible argument that it > is harmful to perform both / -> /usr transitions and to move files > between packages in the same release. > My take away from that is that it may be harmful to move a bunch of > stuff from / -> /usr until we have a plan, and that maintainers should > actively be discouraged from doing so. > I think we should get people to hold off at least until we have a > consensus on that point. I haven't been following this thread in detail because I'm already woefully behind in other things I promised to do (it's not been a productive summer for Debian work), but for what it's worth and from what little I have followed, I agree. The way I'm currently thinking of it is that there are two possible general approaches to the transition: a piecemeal transition of individual packages and a flag-day transition of the whole system. There's a lot of debate right now about the merits of those two proposals and I'm sure there will be hybrid proposals, but this implies two key points. First, we've not fully decided on our overall approach (my understanding of the TC decision is that it didn't pin down the final details). And second, if we are going to do a flag-day transition, *also* doing a piecemeal transition of individual packages may be unnecessary now, may be harmful now (as you pointed out in your message, which I trimmed just for brevity, there are edge-case issues with dpkg behavior mentioned that may imply that), and may be far easier as a cleanup step after the flag-day. That implies that we should stop doing piecemeal transitions now until we decide on whether or not we're doing a flag-day transition and, if we do decide on that, work out the implications for when packages should standardize on /usr paths (if indeed they will ever need to do so; I assume that they probably will out of cleanliness if nothing else, but I'm also not sure it's strictly needed). -- Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
| From | Niels Thykier <niels@thykier.net> |
|---|---|
| Date | 2021-08-25 20:40 +0200 |
| Subject | Re: Debhelper and /lib/systemd vs /usr/lib/systemd |
| Message-ID | <CQ5YC-51J-17@gated-at.bofh.it> |
| In reply to | #101334 |
Sam Hartman: > > TL;DR: Should we hold off on moving stuff from / to /usr in packages > until we develop our plan? > If so, how do we communicate that to people? > >>>>>> "Russ" == Russ Allbery <rra@debian.org> writes: > > Russ> Simon Richter <sjr@debian.org> writes: > >> 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. > > Russ> [...] > > Russ> I think this implies that writing something in Policy about > Russ> this would be premature. The issues you raise are related to > Russ> something new that is being discussed and would be part of a > Russ> migration plan to a merged /usr world. > > Russ, I agree with you that it's premature to document this in policy. > > However, Simon has raised what I think is a credible argument that it > is harmful to perform both / -> /usr transitions and to move files > between packages in the same release. > My take away from that is that it may be harmful to move a bunch of > stuff from / -> /usr until we have a plan, and that maintainers should > actively be discouraged from doing so. > > I think we should get people to hold off at least until we have a > consensus on that point. > > And this is by no means theoretical. > > As was discussed here, recent debhelper (has or at least had) changed > from installing systemd units in /lib/systemd/system to > /usr/lib/systemd/system. > > That is totally fine interms of usermerged stuff, but sets up a > potential problem . > > Suppose we have a program foo that ships a daemon and also a systemd > unit to run it. > > Later we discover that foo is kind of useful in desktop situations and > other situations where it wants to be started as needed and possibly > not even by systemd. > So, we want to split out the foo package into foo containing the daemon > binary and foo-system (recommended by foo) containing the systemd unit. > > The maintainer may not even be thinking about how debhelper moved around > the unit file. > > foo-system replaces/breaks the old version of foo. > > I think the following series of operations would result in the unit file > disappearing on a usermerged system: > > * user has old foo with /lib/systemd/system/foo.service > As I understand it, the issue does not depend on whether "usrmerge" is run before or after installing the "/lib" version of "foo". On that assumption, running "usrmerge" as a part of the upgrade and "cleaning up" in bookworm+1 is liable to exactly the same risk as before. Which means that we are likely "just" debating on when we want to risk to occur. The difference for me being that people would forgot about this issue in bookworm+1 and assume that migration is over with no risk left. On that front, I prefer to take my chances with breaking bookworm while it is fresh in our minds rather than breaking bookworm+1 when every body forgot about it. That said ... > * user attempts to upgrade and installs foo-system as part of upgrade > > * foo is deconfigured because of the breaks on foo-system > > * foo-system is unpacked, including > /usr/lib/systemd/system/foo.service. On the usrmerged system, that > overwrites the existing foo.service since dpkg doesn't know about the > aliasing > > * foo is upgraded. From dpkg's standpoint it looks like > /lib/systemd/system/foo.service disappeared, but since the file still > exists it is removed. > > So the user ends up with no unit. > > I think this is particular insidious because the maintainer might not > even know that they had moved files from / to /usr, or if they knew they > might have not been paying enough attention to provide special care. > > Do people agree that we want to hold off on this sort of thing until we > get a plan? > This strongly depends on: * Who volunteered to be the "we" that provide this plan? * When is "until" we have a defined plan? For concrete values of those definitions, I can be convinced to stop further changes and rollback the systemd / -> /usr change. However, as long as these definitions are variations of "somebody" or "everyone" or "the project" and "eventually" or "when it is ready", then I am not convinced that waiting is the right option. For now, I will hold on further "/ -> /usr" changes in debhelper, but I am not convinced that I should actively rollback the changes already made. Thanks, ~Niels PS: Guesstimates suggests that there 16.5 months until the transition freeze assuming the release team keeps the current cadence.
[toc] | [prev] | [next] | [standalone]
| From | Sam Hartman <hartmans@debian.org> |
|---|---|
| Date | 2021-08-25 22:10 +0200 |
| Subject | Re: Debhelper and /lib/systemd vs /usr/lib/systemd |
| Message-ID | <CQ7nH-5ZV-1@gated-at.bofh.it> |
| In reply to | #101375 |
[Multipart message — attachments visible in raw view] — view raw
>>>>> "Niels" == Niels Thykier <niels@thykier.net> writes:
Niels> As I understand it, the issue does not depend on whether
Niels> "usrmerge" is run before or after installing the "/lib"
Niels> version of "foo". On that assumption, running "usrmerge" as
Niels> a part of the upgrade and "cleaning up" in bookworm+1 is
Niels> liable to exactly the same risk as before.
I don't think so.
My assumption is that we will eventually produce a dpkg that handles
this situation better.
I think that every time we move files from / to /usr inside a package
before that new dpkg is introduced,
we increase our risk.
So my hope is that debhelper and maintainers refrain from moving files
from / to /usr prior to being able to depend on an as yet unwritten
dpkg.
I think that if debhelper moves systemd units and later a maintainer
moves units between packages, we can run into trouble with today's
dpkg. So we could potentially run into trouble as soon as someone
installs such a package from testing onto a bullseye system.
If debhelper were to hold off until after a fixed dpkg exists and we can
guarantee it is available,
I think that we avoid the risk of files disappearing.
So, based on my understanding, I think the risk is worse today than it
would be if we rolled back the debhelper change.
Put another way.
You can choose any two of:
1) alias things outside of dpkg I.E. usrmerge moves files and creates
symlinks
2) Move files inside a package within the knowledge of dpkg
3) move files between packages.
If you choose all 3, files may disappear depending on upgrade ordering.
We've already chosen 1 with the buster debootstrap change.
We often choose 3 as part of regular package reorganization.
I think we should not choose 2.
It's possible I'm missing something .
If so, I'd appreciate help understanding what it is.
This strongly depends on:
> * Who volunteered to be the
> "we" that provide this plan?
> * When is "until" we have a
> defined plan?
So, I think that the discussions here have been converging on things
that would work.
I'm happy to volunteer to assist in trying to find what consensus there
is if that helps.
The discussion here has convinced me at least that actually
canonicalizing paths (making the path inside the package match reality)
is not a safe thing to do until dpkg is changed.
I do think we could force usrmerge (or something similar) to be
installed without changing dpkg.
The dpkg maintainer hasn't been happy with the discussions here, and I
think facilitating to a level where Guillem is part of the consensus is
beyond my skill.
So I don't actually know how to get to something actionable. I do
believe the chance of breakage if we move around paths inside packages
is high enough that we should block path canonicalization on a dpkg that
can handle that, even if that takes a long time.
[toc] | [prev] | [next] | [standalone]
| From | Simon Richter <sjr@debian.org> |
|---|---|
| Date | 2021-08-25 23:10 +0200 |
| Subject | Re: Debhelper and /lib/systemd vs /usr/lib/systemd |
| Message-ID | <CQ8jL-6yw-9@gated-at.bofh.it> |
| In reply to | #101380 |
Hi,
On 25.08.21 21:45, Sam Hartman wrote:
> The dpkg maintainer hasn't been happy with the discussions here, and
> I think facilitating to a level where Guillem is part of the
> consensus is beyond my skill.
The discussion so far has been around the question whether there is
actually a problem and whether it is actually required for the dpkg
database to be consistent with the file system. It is unsurprising that
the dpkg maintainer has an opinion about that.
> So I don't actually know how to get to something actionable. I do
> believe the chance of breakage if we move around paths inside
> packages is high enough that we should block path canonicalization on
> a dpkg that can handle that, even if that takes a long time.
We have a few half-baked solution proposals.
Combining the parts from Ted Ts'o (for usrmerged systems) and mine (for
not-yet usrmerged systems) would be the complex and generic approach.
I think I've also seen some ideas along the lines of "have the usrmerge
package patch the dpkg database", which would be simpler.
Would it make sense to start a wiki page?
Simon
[toc] | [prev] | [next] | [standalone]
| From | Niels Thykier <niels@thykier.net> |
|---|---|
| Date | 2021-08-25 23:30 +0200 |
| Subject | Re: Debhelper and /lib/systemd vs /usr/lib/systemd |
| Message-ID | <CQ8D7-6G6-3@gated-at.bofh.it> |
| In reply to | #101383 |
Simon Richter: > Hi, > > On 25.08.21 21:45, Sam Hartman wrote: > >> The dpkg maintainer hasn't been happy with the discussions here, and >> I think facilitating to a level where Guillem is part of the >> consensus is beyond my skill. > > The discussion so far has been around the question whether there is > actually a problem and whether it is actually required for the dpkg > database to be consistent with the file system. It is unsurprising that > the dpkg maintainer has an opinion about that. > >> So I don't actually know how to get to something actionable. I do >> believe the chance of breakage if we move around paths inside >> packages is high enough that we should block path canonicalization on >> a dpkg that can handle that, even if that takes a long time. > > We have a few half-baked solution proposals. > > Combining the parts from Ted Ts'o (for usrmerged systems) and mine (for > not-yet usrmerged systems) would be the complex and generic approach. > > I think I've also seen some ideas along the lines of "have the usrmerge > package patch the dpkg database", which would be simpler. > > Would it make sense to start a wiki page? > > Simon > As I understand it, the "have usrmerge package patch the dpkg database" approach will only work if we ensure that each and every package stop using / in bookworm+1. Else we are back to the same problem that Sam listed with package splits (just with the paths inverted). That is, a solution based on that plan should also involve a plan for getting each and every package affected by the usrmerge updated in bookworm+1. Thanks, ~Niels
[toc] | [prev] | [next] | [standalone]
| From | Andreas Metzler <ametzler@bebt.de> |
|---|---|
| Date | 2021-08-26 19:40 +0200 |
| Subject | Re: Debhelper and /lib/systemd vs /usr/lib/systemd |
| Message-ID | <CQrw6-2Hq-15@gated-at.bofh.it> |
| In reply to | #101385 |
On 2021-08-25 Niels Thykier <niels@thykier.net> wrote:
[...]
> As I understand it, the "have usrmerge package patch the dpkg database"
> approach will only work if we ensure that each and every package stop
> using / in bookworm+1.
Hello,
you missed the second part of the "plan". Editing dpkg database syncs
the db with reality. In addition to that we need:
| 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.
A one-time rewrite does not solve the issue. We cannot guarantee that
dpkg never sees a file with /bin/foo because of local or third party
packages.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
[toc] | [prev] | [next] | [standalone]
| From | Niels Thykier <niels@thykier.net> |
|---|---|
| Date | 2021-08-25 23:20 +0200 |
| Subject | Re: Debhelper and /lib/systemd vs /usr/lib/systemd |
| Message-ID | <CQ8tr-6Cc-5@gated-at.bofh.it> |
| In reply to | #101380 |
Sam Hartman: >>>>>> "Niels" == Niels Thykier <niels@thykier.net> writes: > > Niels> As I understand it, the issue does not depend on whether > Niels> "usrmerge" is run before or after installing the "/lib" > Niels> version of "foo". On that assumption, running "usrmerge" as > Niels> a part of the upgrade and "cleaning up" in bookworm+1 is > Niels> liable to exactly the same risk as before. > > I don't think so. > My assumption is that we will eventually produce a dpkg that handles > this situation better. I can appreciate the allure of assuming that "a fixed dpkg" appears and solves the entire problem. It would certainly make all the problem go away *if* it appears. I am not ready to believe in that dpkg as a solution to the bookworm release because the dpkg development flow has never been "fast" due to a strong focus on "a generic solution that gets it right in every case" - and I expect it to be even slower than usually given how demotivated Guillem feels and the complexity involved in such a change to dpkg. And until the "fixed" dpkg materializes, every package shipping something has to keep files in /lib - even if that is a decade after the bookworm release - or risk breaking if they later need to split the package in the same release cycle. To me, that sounds like we will drag the transition on "until the fixed dpkg comes along" no matter how long it takes. Finishing the transition is a key element for me in the transition. > [...] > So my hope is that debhelper and maintainers refrain from moving files > from / to /usr prior to being able to depend on an as yet unwritten > dpkg. > For me, this reads as "until = eventually", which I stated I would find unconvincing. For the record, I did not immediately expect a better answer which is also why I am waiting with moving forward in case a better answer materializes "soon". > I think that if debhelper moves systemd units and later a maintainer > moves units between packages, we can run into trouble with today's > dpkg. So we could potentially run into trouble as soon as someone > installs such a package from testing onto a bullseye system. > > If debhelper were to hold off until after a fixed dpkg exists and we can > guarantee it is available, > I think that we avoid the risk of files disappearing. > So, based on my understanding, I think the risk is worse today than it > would be if we rolled back the debhelper change. > > > [...] > > > It's possible I'm missing something . > If so, I'd appreciate help understanding what it is. > On the assumption that a "fixed" dpkg will appear in bookworm, I would agree with you. However, I do not believe in that assumption/timeline - to explain why I believe we fundamentally disagree on the priority/solution. > This strongly depends on: > >> * Who volunteered to be the >> "we" that provide this plan? >> * When is "until" we have a >> defined plan? > > So, I think that the discussions here have been converging on things > that would work. > I'm happy to volunteer to assist in trying to find what consensus there > is if that helps. > I appreciate you volunteering to a part of it. My interest in a detailed transition plan with a fixed end date where we are *done* with the "clean up" no later than bookworm+1. I do not see that directly in these discussions - but certainly, a consensus is probably the first step there. Maybe the consensus will motivate someone to volunteer to create the plan. (Side-note my desired timeline implies that a "fixed" dpkg lands in bookworm.) > [...] > > So I don't actually know how to get to something actionable. I do > believe the chance of breakage if we move around paths inside packages > is high enough that we should block path canonicalization on a dpkg that > can handle that, even if that takes a long time. > I would strongly prefer a timely actionable transition plan that does not involve assuming a "fixed" dpkg will show up and magically fix everything when the volunteer working dpkg is strongly demotivated by this transition. In the absence of such a transition plan ... If the project consensus of this discussion is aligned with the belief that we should block decentralized volunteer work on the transition, I will respect the decision. ~Niels
[toc] | [prev] | [next] | [standalone]
| From | Sam Hartman <hartmans@debian.org> |
|---|---|
| Date | 2021-08-26 18:00 +0200 |
| Subject | Re: Debhelper and /lib/systemd vs /usr/lib/systemd |
| Message-ID | <CQpXl-1Fr-9@gated-at.bofh.it> |
| In reply to | #101384 |
>>>>> "Niels" == Niels Thykier <niels@thykier.net> writes:
Niels> If the project consensus of this discussion is aligned with
Niels> the belief that we should block decentralized volunteer work
Niels> on the transition, I will respect the decision.
I was really frustrated reading that, and I hope that my reading is more
loaded than you meant.
If what you're saying is that you'll respect it if the project consensus
is that individual package maintainers should not move paths around at
this time, then I think that's the key question.
I'll point out that we get a lot of value even if we don't move paths
around in packages.
In particular, we get a uniform environment where we can depend on a
single directory layout.
That removes classes of bugs even if we don't get to update canonical
paths.
What I originally heard in your statement was a consensus that volunteers are not needed,
and I don't think anyone support that.
I think there are several ways in which volunteers are needed:
* Working on figuring out how to trigger the transition.
Ideas included so far are to make usrmerge transitively essential, to
include such code in dpkg, or to detect non usrmerged systems and force
the administrator to do something manually.
* Figure out whether we'll require build chroots to remain
non-usr-merged in bookworm (thus requiring some way to generate such a
system) or whether we'll somehow guarantee that usrmerge transition
happens at the beginning of the upgrade.
* Finish out the discussion Simon Richter and Ted Ts'o are having
exploring changes in dpkg behavior.
* Write patches for dpkg.
I appreciate that getting those patches merged may be a challenge, but
the situation is different with patches in hand.
Yes, a lot more of these volunteer tasks are about talking to people
than normal package maintenance.
And some of them are kind of tricky. I don't even know who makes the
decision about what the upgrade procedure is between releases in Debian.
I mean I can guess to some extent the release team is involved and to
some extent the release notes authors are involved.
And I'd probably talk to the apt maintainers too.
But I'm honestly not sure how we'd evaluate a proposed change to the
upgrade procedure.
[toc] | [prev] | [next] | [standalone]
| From | Niels Thykier <niels@thykier.net> |
|---|---|
| Date | 2021-08-26 19:50 +0200 |
| Subject | Re: Debhelper and /lib/systemd vs /usr/lib/systemd |
| Message-ID | <CQrFM-2L1-3@gated-at.bofh.it> |
| In reply to | #101406 |
Sam Hartman: >>>>>> "Niels" == Niels Thykier <niels@thykier.net> writes: > > Niels> If the project consensus of this discussion is aligned with > Niels> the belief that we should block decentralized volunteer work > Niels> on the transition, I will respect the decision. > > I was really frustrated reading that, and I hope that my reading is more > loaded than you meant. Hi Sam, I am sorry that my email caused you frustration. That part was loaded with my own frustration over the situation and how we - as a project - are handling the transition, which I failed to weed out in my self-review of my outgoing email. Since I do not know to what extend you took it personally, I want you know that none of that frustration was aimed at you as an individual. Once again, if you in any way felt that, then I apologies for that part. > If what you're saying is that you'll respect it if the project consensus > is that individual package maintainers should not move paths around at > this time, then I think that's the key question. > That is what I wanted to say. > I'll point out that we get a lot of value even if we don't move paths > around in packages. > In particular, we get a uniform environment where we can depend on a > single directory layout. > That removes classes of bugs even if we don't get to update canonical > paths. > I believe we both agree on those statements being true (like many of the previous ones). Where we seem to disagree is what should have priority over other things. I sense that the timeliness of completion is of less importance to you compared to other values and I respect that. However, I will be considerably more demotivated by what I feel is a never-ending transition than I am motivated by all of the points you listed above. Which makes it a net-loss for me in years to come even if it is a net-win for many others if the transition is not resolved in a timely fashion. > > > What I originally heard in your statement was a consensus that volunteers are not needed, > and I don't think anyone support that. > My frustration had a different direction than the one what you seemed to have understood it as, which is why I will not answer your extended follow up to that part in detail - nor do I intend to expand on my original words because I doubt it will make any of us happy. Once again, my sincerest apologies for frustration. Finally, I will retract myself from this debate for the time being. I do not feel I have anything additional of constructive value to add to it nor have enough spoons to invest to become a constructive participant. I will await the evaluation of the consensus. I kindly ask that you CC that to debhelper@packges.debian.org (or, at your choosing, report it as a bug if it involves reverting the change) as I am not sure I will keep track of this thread any more. ~Niels
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <wouter@debian.org> |
|---|---|
| Date | 2021-08-25 18:10 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CQ3Ds-3Jh-9@gated-at.bofh.it> |
| In reply to | #101323 |
On Mon, Aug 23, 2021 at 08:23:50AM -0700, Russ Allbery wrote:
> 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.
The problem here is also that if there are two packages like that, on an
usrmerge system, we would not know this is happening.
Let's say there's a package "foo" which installs /usr/bin/foo, and an
package "binfoo" which installs "/bin/foo". In the current situation,
dpkg would not know that the two files are equivalent, and would happily
overwrite /usr/bin/foo with /bin/foo if "binfoo" was installed after
"foo".
Then when the user notices the "foo" program is not doing what they
believe it should be doing and runs "reportbug /usr/bin/foo", reportbug
will file the bug against the package "foo" rather than the package
"binfoo" which is the actual package whose binary they are trying to
use.
In contrast, if foo and binfoo both install "/bin/foo" (or both install
"/usr/bin/foo", either way works), then dpkg will complain at
installation time that one of the two packages tries to overwrite a file
from the other and refuse to continue.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2021-08-25 19:00 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CQ4pP-40h-3@gated-at.bofh.it> |
| In reply to | #101366 |
Wouter Verhelst <wouter@debian.org> writes: > On Mon, Aug 23, 2021 at 08:23:50AM -0700, Russ Allbery wrote: >> 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. > The problem here is also that if there are two packages like that, on an > usrmerge system, we would not know this is happening. I agree, of course, but I don't see a way in which Policy can help with that problem unless this packaging decision was intentional and the person who made that decision would have chosen otherwise if Policy had said to not do it. This seems more like an appropriate check for an archive-wide QA tool looking for cross-package problems. (That said, the molly-guard example does seem to indicate that at least one packager in the past did not realize this would be a problem.) -- Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
| From | Guillem Jover <guillem@debian.org> |
|---|---|
| Date | 2021-08-25 20:10 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CQ5vA-4RL-13@gated-at.bofh.it> |
| In reply to | #101369 |
On Wed, 2021-08-25 at 09:57:09 -0700, Russ Allbery wrote:
> Wouter Verhelst <wouter@debian.org> writes:
> > The problem here is also that if there are two packages like that, on an
> > usrmerge system, we would not know this is happening.
Also this does not need to come from "buggy" packaging practices.
> I agree, of course, but I don't see a way in which Policy can help with
> that problem unless this packaging decision was intentional and the person
> who made that decision would have chosen otherwise if Policy had said to
> not do it.
> This seems more like an appropriate check for an archive-wide QA tool
> looking for cross-package problems.
I've said this many times over the months (years!?), that while this
can easily affect stuff from the archive, which we do control, where
policy applies and where we could try to poorly reimplement the checks
that dpkg does to detect them in some QA checker, even though the
following problems would still apply:
- the checks cannot be performed (only) over static snapshots of
the archive, as this would affect partial upgrades too,
- the checks would need to take into account packages we have
stopped shipping way in the past as those can linger around
installed,
- the checks would have a hard time with the non-declarative side
of the packaging stack,
is that something else I expect to have a non-zero chance to bite users
are all those common practices that people give for granted and that we
have supposedly supported in the past, as guaranteed by our packaging
system, such as:
- keeping installed packages that have stopped shipping in Debian,
- installation of packages from third-parties, or from local
overlays or similar, or even rebuilt forks of packages from Debian,
- installation or holding of Debian packages from older releases,
- local diversions or alternatives,
which are out of our QA reach.
The fact that the supporters of a *filesystem layout* have been happy
to dismiss and ignore this and have been pushing for what I think can
be easily described as the worst ever "transition" done in Debian, very
sadly, for me this whole topic marks a before and after in Debian, and
has put my trust in the technical side of the project into question.
Of course some of those supporters are now agreeing these problems can
be insidious, progress I guess. And at the same time others are claiming
that acknowledging those problems would hold back the entire distribution,
while others are now saying we should stop doing packaging changes because,
well, these problems perhaps are potentially problematic, the irony.
And then we get people raving over what's the worst and most atrocious
hacks to pile on into dpkg to try to workaround the actual root cause
(turtles^Wnasty hacks and kludges all the way down I guess). Which I
obviously expect to eventually be coerced into merging into dpkg at
some point or another via our esteemed Authority.
From where I'm sitting Debian is the project that lost its way…
Sadly,
Guillem
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2021-08-25 22:30 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CQ7H4-66p-9@gated-at.bofh.it> |
| In reply to | #101374 |
Guillem Jover <guillem@debian.org> writes: > The fact that the supporters of a *filesystem layout* have been happy to > dismiss and ignore this and have been pushing for what I think can be > easily described as the worst ever "transition" done in Debian, very > sadly, for me this whole topic marks a before and after in Debian, and > has put my trust in the technical side of the project into question. I agree that you've been pointing out potential problems for years and that your warnings have been at least partly vindicated by the problems we are indeed seeing. My understanding (which may be entirely incorrect, in which case please let me know what your preferred solution actually is!) is that your preferred solution was to migrate individual packages. What I'm hearing from the frequent threads in debian-devel is that a sufficient number of Debian contributors have rejected that approach (for various reasons) as to make that solution not viable. In other words, my reading of the consensus is that this option has effectively been vetoed by the rest of the project (noting that this veto was certainly not unanimous). Please note that I'm not taking a position on the merits of that decision, simply noting that, based on my reading of debian-devel, this is has what has happened, and I do not believe it will be possible at this point to convince the project as a whole to unwind usrmerge and go back to doing individual package migrations. Given that as a design constraint (we will not be doing this transition via one-by-one changes to each package), what would you support as a good architectural solution to this transition? Even ruling out that approach, the design space seems large and flexible; surely there must be some coherent way of doing this transition that does not require individual action for each affected package and preserves some of the "be done with it" design goals of the current usrmerge approach while avoiding the problems you have pointed out. I think it's obvious that any such design will require support from dpkg. You're very understandably upset that people are insisting on a solution that you feel is clearly incorrect, but I think that's also how the people who are disagreeing with you are feeling, and as long as that's true on both sides it's hard to see how we're going to arrive at a solution that isn't going to make you even more unhappy. In order to break this deadlock, I think we have to have a design discussion in the shared space of mutually agreeable solutions and not (on all sides) retreat back to a single preferred architectural decision and only point out the problems with any other approach. -- Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <wouter@debian.org> |
|---|---|
| Date | 2021-08-25 21:50 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CQ74m-5E0-7@gated-at.bofh.it> |
| In reply to | #101369 |
On Wed, Aug 25, 2021 at 09:57:09AM -0700, Russ Allbery wrote:
> Wouter Verhelst <wouter@debian.org> writes:
> > On Mon, Aug 23, 2021 at 08:23:50AM -0700, Russ Allbery wrote:
>
> >> 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.
>
> > The problem here is also that if there are two packages like that, on an
> > usrmerge system, we would not know this is happening.
>
> I agree, of course, but I don't see a way in which Policy can help with
> that problem unless this packaging decision was intentional and the person
> who made that decision would have chosen otherwise if Policy had said to
> not do it.
>
> This seems more like an appropriate check for an archive-wide QA tool
> looking for cross-package problems.
Indeed, and that was the point I was trying to make: it's not something
Policy can help with, unless it is intentional (and it is my belief that
this is not likely to be the case).
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
[toc] | [prev] | [next] | [standalone]
| From | Simon Richter <sjr@debian.org> |
|---|---|
| Date | 2021-08-25 22:00 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CQ7e1-5Hq-1@gated-at.bofh.it> |
| In reply to | #101369 |
Hi,
On 25.08.21 18:57, Russ Allbery wrote:
>> The problem here is also that if there are two packages like that, on an
>> usrmerge system, we would not know this is happening.
> I agree, of course, but I don't see a way in which Policy can help with
> that problem unless this packaging decision was intentional and the person
> who made that decision would have chosen otherwise if Policy had said to
> not do it.
I'd expand the definition of Conflicts/Replaces though: packages that
use names that conflict because of usrmerge would need to declare it,
because as soon as we teach dpkg to recognize these conflicts, the
packages would fail to install on stable.
> This seems more like an appropriate check for an archive-wide QA tool
> looking for cross-package problems.
We have a tool that looks for missing Conflicts/Replaces, and that tool
needs to be extended as well.
Simon
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2021-08-25 22:10 +0200 |
| Subject | Re: merged /usr vs. symlink farms |
| Message-ID | <CQ7nI-5ZV-3@gated-at.bofh.it> |
| In reply to | #101379 |
Simon Richter <sjr@debian.org> writes: > I'd expand the definition of Conflicts/Replaces though: packages that > use names that conflict because of usrmerge would need to declare it, > because as soon as we teach dpkg to recognize these conflicts, the > packages would fail to install on stable. Yes, that's probably the most appropriate place to make a change to Policy to clarify this. -- Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
Page 7 of 13 — ← Prev page 1 … 5 6 [7] 8 9 … 13 Next page →
Back to top | Article view | linux.debian.devel
csiph-web