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 3 of 13 — ← Prev page 1 2 [3] 4 5 … 13 Next page →
| From | Brian Thompson <brian@hashvault.io> |
|---|---|
| Date | 2021-07-21 04:10 +0200 |
| Message-ID | <CD9Ql-85Y-1@gated-at.bofh.it> |
| In reply to | #100843 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, 2021-07-20 at 21:13 -0400, Polyna-Maude Racicot-Summerside wrote: > Ended up with a 3 month useless discussion regarding if this would > give > a bad impression, that we need to use node for doing development. > Later on I was working on a plugin that treated huge amount of data. > So > I introduced Vue.JS, again a three month discussion with people > saying > it's a overhead, even after explaining that you can't always do > server > side processing and serve all the data at a time. Even if people > didn't > understand a word about the global concept and the system as a whole, > they halted the project. > So I just let go my participation. > Now 4 years later, they are integrating Vue.JS and Node doing code > validation while development. > > One of the main reason some people don't want to invest time in FOSS > project is exactly because of that type of toxic situation that make > everyone look like crazy nut head. I find it pretty crazy that you think FOSS is toxic, when in reality the only toxic thing about this situation was when you labeled a discussion as "useless". They didn't want to use your technology stack four years ago. Now they do. Throwing a temper tantrum when you don't get your way isn't doing anyone else any favors. P.S. You may be the biggest hippocrit in these mailing lists. -- BT
[toc] | [prev] | [next] | [standalone]
| From | Polyna-Maude Racicot-Summerside <debian@polynamaude.com> |
|---|---|
| Date | 2021-07-21 04:40 +0200 |
| Message-ID | <CDajn-8la-1@gated-at.bofh.it> |
| In reply to | #100845 |
[Multipart message — attachments visible in raw view] — view raw
Hi, On 2021-07-20 10:07 p.m., Brian Thompson wrote: > On Tue, 2021-07-20 at 21:13 -0400, Polyna-Maude Racicot-Summerside > wrote: >> Ended up with a 3 month useless discussion regarding if this would >> give >> a bad impression, that we need to use node for doing development. >> Later on I was working on a plugin that treated huge amount of data. >> So >> I introduced Vue.JS, again a three month discussion with people >> saying >> it's a overhead, even after explaining that you can't always do >> server >> side processing and serve all the data at a time. Even if people >> didn't >> understand a word about the global concept and the system as a whole, >> they halted the project. >> So I just let go my participation. >> Now 4 years later, they are integrating Vue.JS and Node doing code >> validation while development. >> >> One of the main reason some people don't want to invest time in FOSS >> project is exactly because of that type of toxic situation that make >> everyone look like crazy nut head. > > I find it pretty crazy that you think FOSS is toxic, when in reality > the only toxic thing about this situation was when you labeled a > discussion as "useless". They didn't want to use your technology stack > four years ago. Now they do. Throwing a temper tantrum when you don't > get your way isn't doing anyone else any favors. > You either cherrypicked or only took what you wanted in what I said. So I'll do it again... I was asked by one of the project manager to implement a new plugin that would allow some machine learning and data processing (using chart with plotly.js using database on a CMS). To do so efficiently, I had to use some type of client side processing and decided to use Vue.JS. This didn't change nothing for anyone except me. But all the developers started saying it wasn't good because it would project the idea that we need to use Node to do development (false) or that Vue.JS is needed for the CMS (false). Most of the person talking about this were people who didn't have a clue what they were talking about. Mostly people doing translation for text string, HTML/CSS front end themes and such. Most of the time, when we talked about PHP they would say "that they ain't developer". For you information, I didn't throw a tamper tantrum, I simply felt that my time would be better invested somewhere I could use my time in a positive manner. Having to explain that "It's not because there's a package.json file that you'll need Node ecosystem. As there's already a .gitla-ci.yml and you don't need to have a Gitlab runner on your PC to do development". Having to explain that sending all the data at one time, when processing thousands of record is not a possibility if you want to have a system that can be scaled up. And much more... This is time consuming and doesn't help much going a project forward. It wasn't a technology stack that I've chosen but the one that was requested by the project manager who paid me. But I had to deal with those questions on the mailing list. And I did get tired so went somewhere else... So we we're in front of people that (like many) had a opinion but didn't have much to support it. I don't know many business we're we pass more time discussing about solution than implementing them. Unless, I got it wrong, and FOSS project are some type of IT consultant box ? I come from health science and we do stuff, don't smoke butterfly powder thinking about what would be the best in a ideal world. I don't think about what's the best solution for a ideal world. And if I was running Windows for the computer used for medical purpose in my office, there was one reason : I didn't have nothing that made if efficient for me to go Linux. All the advantage were overwhelmed by the time consuming of process changing, staff training or simply because no such solution existed. If all the time wasted in fork was used to making project grow better then it'd be long ago that we wouldn't see as many Windows. > P.S. You may be the biggest hippocrit in these mailing lists. > You don't have a clue who I am... So let me put you in the box where it says "I talk about what I don't know and think I'm soooo great". -- Polyna-Maude R.-Summerside -Be smart, Be wise, Support opensource development
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+debian-devel@zugschlus.de> |
|---|---|
| Date | 2021-07-21 08:20 +0200 |
| Subject | Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) |
| Message-ID | <CDdKh-263-1@gated-at.bofh.it> |
| In reply to | #100837 |
On Tue, 20 Jul 2021 23:15:33 +0200, Svante Signell <svante.signell@gmail.com> wrote: >It is really stunning that the Debian project, including the TC >overrides the dpkg developer and maintainer Guillem, and still using >dpkg for package management. Maybe Debian should switch to some other >software, like rpm-based used by Fedora or even guix used by GNU?? This suggestion doesnt get any smart by repeating it. -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+debian-devel@zugschlus.de> |
|---|---|
| Date | 2021-07-20 21:40 +0200 |
| Subject | Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) |
| Message-ID | <CD3KV-4ob-3@gated-at.bofh.it> |
| In reply to | #100834 |
On Tue, 20 Jul 2021 14:47:04 +0200, Svante Signell <svante.signell@gmail.com> wrote: >According to the dpkg developer and maintainer Guillem users can still >rescue their systems from merged-/usr-via-aliased-dirs with the aid of >dpkg-fsys-usrunmess(8), see >https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Does_dpkg_support_merged-.2Fusr-via-aliased-dirs.3F The naming of the utility alone gives me the impression that we have a dpkg maintainer who has gone to war with the rest of the distribution. I am not sure whether Debian should accept that. Greetings Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Thorsten Glaser <tg@debian.org> |
|---|---|
| Date | 2021-07-22 04:00 +0200 |
| Subject | a little productivity on the side (was Re: merged /usr considered harmful) |
| Message-ID | <CDwad-4xV-1@gated-at.bofh.it> |
| In reply to | #100833 |
Andreas Metzler dixit:
>1. Make merged-/usr-via-aliased-dirs the only supported layout and make
>this information available to apt. (Like we did for multi-arch-support.)
>2. After that individual packages can safely move files from / to /usr,
>pre-depending on merged-usr-support.
This will still break “dpkg -S $(which programname)”, which I use a lot.
And tons of other stuff. All aliasing schemes will. Just keep supporting
unmerged filesystems and requiring /usr to be there at the time control
is handed to init(8).
A little bit more positively, as I recently switched my sid systems to
bullseye, I was wondering which packages I now have to manually down‐
grade; additionally, a lot of “dust” they had accumulated over time.
I am vaguely aware of aptitude having parts of this but don’t use it,
so here we are:
https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=shellsnippets/shellsnippets.git;a=blob;f=mksh/debian-dev/aptcheck;hb=HEAD
This little tool (the shellsnippets.git repository is also mirrored
to github for those who prefer there) asks dpkg for the status of all
packages (or those listed as arguments), complains about all which are
not ii or hi, and for those it checks (via apt-cache policy as that was
easier/more straightforward than apt-cache showpkg) whether the installed
version is available from any repository and up-to-date (ignoring back‐
ports{,-sloppy}); neighbouring versions which *are* in repositories are
shown as well (both bpo and not; for both, the respective highest one).
This script needs…
https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=shellsnippets/shellsnippets.git;a=blob;f=mksh/progress-bar;hb=HEAD
(also on github in the same repository, or in MirBSD CVS)
… to be in the same or parent directory to display the progress bar
which makes the long wait (I had 100% CPU utilisation on one core by
apt-cache alone) bearable. You can redirect stdout still, though ☻
It found a surprising amount of packages I hope the maintainers filed
unblock requests for ;-)
Improvements welcome… that don’t involve rewriting this in a programming
language beginning with b or p anyway ;-) also, comments.
I can imagine it being useful in all sorts of situations, not just the
one I’m currently using it for. (Also, “what packages I use were removed
from Debian?” etc.)
Development was sponsored by ⮡ tarent solutions GmbH
Enjoy,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
[toc] | [prev] | [next] | [standalone]
| From | Guillem Jover <guillem@debian.org> |
|---|---|
| Date | 2021-07-20 11:20 +0200 |
| Message-ID | <CCU4W-70b-3@gated-at.bofh.it> |
| In reply to | #100817 |
On Mon, 2021-07-19 at 15:10:42 +0200, Michael Biebl wrote: > Am 19.07.21 um 03:36 schrieb Guillem Jover: > > What I've also said multiple times, is that > > merged-usr-via-moves-and-symlink-farms could have been implemented in > > a fully automated way, by debhelper, w/o requiring any maintainer scripts, > > all with full cooperation and managed by dpkg, with .debs shipping > > actual tracked pathnames > What you propose is, that each and every package does its /usr-merge > transition on its own. This only works, if packages are independent (enough) > so this actually works. > Unfortunately this is not the case. Take PAM for example. You can't just > recompile src:pam and have debhelper automatically move all files to /usr. > This would break all packages that install a PAM plugin. You have a > transition here, involving many packages. > Same is true for udev rules, systemd service files, basically every package > that provides interfaces/hooks to other packages is affected. > So it's not that simple unfortunately. You can't fully automate that. Not at all. pam or whatever we transition via cooperation from dpkg, would be kept compiling using the directories it currently uses, and debhelper would simply move the objects on the .deb from «/» to «/usr», and create the compat symlinks. That means pam, and any plugins migrated or not, would still be available in the current pathnames causing no breakage. This part would be done automatically. And as I've said elsewhere, removal of the compat symlinks would require manual intervention (at the maintainer discretion), at some later time, to modify the configured installation paths (which is something that cannot be automated in debhelper, due to packaging overrides and similar), at which point it can be decided whether to declare say a local pam flag day, or add the needed Breaks and similar, or add support to pam to look in both pathnames to avoid the two previous items. > According to > apt-file search -x '^/(lib|bin|sbin)' > on my Debian sid/amd64 system, we have 1747 packages shipping 24583 files in > those directories. There are *many* such entangled transitions hidden in > there, so I fear this is not manageable. See my comment above, and josch reply. > As Luca pointed out, even distros with a much stricter governance model were > not able to do that. Well if they did it poorly, no wonder, I guess. > The /usr-merge transition as described and decided on in the TC bug, seems > to me is the only viable way forward. I obviously disagree. > Yes, it does break dpkg -S, but your idea of using a list of mapped paths as > in [1] seems like an entirely reasonable approach to solve this. Did you miss the section in the mail you are replying where I mention that f.ex. dpkg tools (dpkg, dpkg-divert, u-a) missing to then detect file conflicts, or files disappearing on moves, or dpkg-deb -x (or tar) destroying merged-/usr-via-aliased-dirs systems? All these, including dpkg -S (which BTW also breaks after paths have been moved, as when say bash ships as /usr/bin/bash, then dpkg -S will also fail to find the expected /bin/bash), are currently affecting any system being installed by the default installer, or ones having been switched by the usrmerge hack. > Once we have this global switch to merged-usr, packages can bit by bit, > completely independent, update their debian/rules to use --prefix=/usr and > after a few years, we don't have any packages anymore installing any files > in /. We could aid this process with a lintian check that flags packages > that install files in /(sbin|bin|lib)/. The same can be said about my proposal, except that then dpkg is kept in the loop, the transition is done safely by dpkg as part of individual package upgrades, instead of having to use something off-band and as disturbing as usrmerge during upgrade, on dpkg's back w/o any cooperation from it… Regards, Guillem
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <wouter@debian.org> |
|---|---|
| Date | 2021-07-22 16:00 +0200 |
| Message-ID | <CDHoZ-38d-5@gated-at.bofh.it> |
| In reply to | #100817 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, Jul 19, 2021 at 03:10:42PM +0200, Michael Biebl wrote:
> Hi Guillem
>
> Am 19.07.21 um 03:36 schrieb Guillem Jover:
> > What I've also said multiple times, is that
> > merged-usr-via-moves-and-symlink-farms could have been implemented in
> > a fully automated way, by debhelper, w/o requiring any maintainer scripts,
> > all with full cooperation and managed by dpkg, with .debs shipping
> > actual tracked pathnames
> I'm convinced this view is way too naive and not implementable in practice
> (and yes, openSUSE is a data point that confirms that)
>
> What you propose is, that each and every package does its /usr-merge
> transition on its own. This only works, if packages are independent (enough)
> so this actually works.
> Unfortunately this is not the case. Take PAM for example. You can't just
> recompile src:pam and have debhelper automatically move all files to /usr.
> This would break all packages that install a PAM plugin. You have a
> transition here, involving many packages.
Why?
Nobody is saying the old path should cease to function. The whole point
of a symlink farm is that *YOU ADD A SYMLINK* to replace the old path.
So then you have /lib/*/security/pam_foo.so ->
/usr/lib/*/security/pam_foo.so and your old-pam plugin will still work
with new-pam (and vice versa) and there is no need for a transition.
I've suggested previously that we can easily make it RC for bookworm to
have a file outside a limited set of directories (/etc and /usr would be
OK, but notably /bin /lib and /sbin wouldn't be) that is not a symlink.
This is easy to detect with a lintian check and reasonably easy to
implement, and would not confuse dpkg *at all*.
But whenever I bring this up, I hear people say "oh but suse tried it
and failed" (well suse aren't using dpkg and there's no reason to assume
we'll have the same problem, why don't we try?) or "oh but the /usr/doc
transition that worked that way 20 years ago took forever" (that was 20
years ago, our tooling is way more advanced these days) or "oh but that
will break bash and you can't upgrade safely without bash" (true, but
bash is just the one package and we already have /bin/sh be a symlink
and that never made upgrades fail permanently so I don't see how
usrmerge is somehow special).
I've grown tired of the whole discussion, and the "we must go forward
and only our way will work and your ideas are stupid just shut up
already" mentality the proponents of usrmerge seem to have.
I can understand the use case for usrmerge, and I won't cry over my
/bin/sh being essentially the same file as /usr/bin/sh -- but I long for
the good old days of Debian where we did things the right way, not
whichever is the fastest, because that way, things would *work* in *all*
cases, not just the cases that the proponents of some new feature care
about.
It took us forever to implement the /usr/doc transition, but it was
finished and nobody's machine broke.
It took us a fairly large time to implement multiarch, but we did it and
it works *way* better than in the RPM world.
I fail to see why usrmerge is so special that it can't wait until we do
things the right way.
Sure, there are technical issues with doing things the right way, and we
should deal with them. But just throwing them under the carpet and
deciding they're only a problem for other people isn't going to help
anyone.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2021-07-22 16:30 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CDHS2-3x5-3@gated-at.bofh.it> |
| In reply to | #100857 |
On Thu, 22 Jul 2021 at 15:53:32 +0200, Wouter Verhelst wrote:
> I've suggested previously that we can easily make it RC for bookworm to
> have a file outside a limited set of directories (/etc and /usr would be
> OK, but notably /bin /lib and /sbin wouldn't be) that is not a symlink.
> This is easy to detect with a lintian check and reasonably easy to
> implement
I don't think that works in general without breaking some of Debian's
axioms around Essential packages, as previously described here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636#118
I have a longer mail written with possible ways forward, which I'm
deliberately not sending right now, because the first step in all of these
plans is "release Debian 11" and I don't want to distract the people who
are making that happen (any more than has already happened).
smcv
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <wouter@debian.org> |
|---|---|
| Date | 2021-07-27 12:50 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CFsFb-38y-1@gated-at.bofh.it> |
| In reply to | #100858 |
On Thu, Jul 22, 2021 at 03:20:05PM +0100, Simon McVittie wrote:
> On Thu, 22 Jul 2021 at 15:53:32 +0200, Wouter Verhelst wrote:
> > I've suggested previously that we can easily make it RC for bookworm to
> > have a file outside a limited set of directories (/etc and /usr would be
> > OK, but notably /bin /lib and /sbin wouldn't be) that is not a symlink.
> > This is easy to detect with a lintian check and reasonably easy to
> > implement
>
> I don't think that works in general without breaking some of Debian's
> axioms around Essential packages, as previously described here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636#118
Yes. Those arguments didn't convince me then, and they don't convince me
now.
A package in the essential set could work around the issue by moving a
file around and creating a necessary symlink in preinst rather than
shipping things. The set of Essential packages is small however, and
most packages can ship a compat symlink.
I didn't say we *should* ship compat symlinks; I said we should make
antyhing that is *not* a compat symlink in a particular set of
directories be RC.
> I have a longer mail written with possible ways forward, which I'm
> deliberately not sending right now, because the first step in all of these
> plans is "release Debian 11" and I don't want to distract the people who
> are making that happen (any more than has already happened).
This is so exhausting.
Yes, I know the release is close, and yes, I know that some people are
immensely busy working on that. I want to help them do so in any way I
can, but they're not *required* to read -devel, and "they might read
this and get distracted" seems like a pretty poor argument.
I'm not busy with the release. Are you? If not, you *can* actually come
up with an argument right now, and I promise not to insist on any
decision being made until the release happens, so that those
hypothetical people who *are* busy with the release can still chip in
later if they choose to do so.
Meanwhile, we can still discuss this.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
[toc] | [prev] | [next] | [standalone]
| From | Andreas Metzler <ametzler@bebt.de> |
|---|---|
| Date | 2021-07-27 14:20 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CFudX-49n-1@gated-at.bofh.it> |
| In reply to | #100872 |
On 2021-07-27 Wouter Verhelst <wouter@debian.org> wrote: > On Thu, Jul 22, 2021 at 03:20:05PM +0100, Simon McVittie wrote: >> On Thu, 22 Jul 2021 at 15:53:32 +0200, Wouter Verhelst wrote: >>> I've suggested previously that we can easily make it RC for bookworm to >>> have a file outside a limited set of directories (/etc and /usr would be >>> OK, but notably /bin /lib and /sbin wouldn't be) that is not a symlink. >>> This is easy to detect with a lintian check and reasonably easy to >>> implement >> I don't think that works in general without breaking some of Debian's >> axioms around Essential packages, as previously described here: >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636#118 > Yes. Those arguments didn't convince me then, and they don't convince me > now. > A package in the essential set could work around the issue by moving a > file around and creating a necessary symlink in preinst rather than > shipping things. The set of Essential packages is small however, and > most packages can ship a compat symlink. > I didn't say we *should* ship compat symlinks; I said we should make > antyhing that is *not* a compat symlink in a particular set of > directories be RC. [...] Hello Wouter, I will bite. just for context: Simon said in #978636 that e.g. coreutils a) cannot ship both /usr/bin/mv and /bin/mv (the latter a symlink) in the tarfile since /bin _might_ be a symlink to /usr/bin but b) it needs to provide /bin/mv in unpacked, unconfigured state. Simon then said we needed a flag day where the aliasing-symlinks /bin --> /usr/bin are either guaranteed to exist or forbidden. Once that is know essential packages either ship both /usr/bin/mv and /bin/mv (the latter a symlink) or only ship /usr/bin/mv (with no symlink required.) Afaiu you are suggesting to do somethink like this instead and immediately post bulleye release. ---------------------------------------- preinst upgrade|install if aliasing-symlinks /bin --> /usr/bin # do nothing else mv /bin/mv /usr/bin/mv ln -s /usr/bin/mv /bin/mv fi Plus corresponding error handling code in postrm abort install. ---------------------------------------- I just do not get the benefit. It seems rather complicated with potential for breakage in corner cases and unnecessary since we (CTTE) have essentially decided that there is going to be a cutoff date pre-bookworm-release whereupon package maintainers can rely on the existence of aliasing-symlinks and can simply move the file without any maintainerscripts. It seems to be a waste of work to write complicated maintainerscripts that are only needed as long as we need to handle both usrmerge-d and non-usrmerge-d systems. 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 | Wouter Verhelst <wouter@debian.org> |
|---|---|
| Date | 2021-07-27 15:30 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CFvjH-4OZ-3@gated-at.bofh.it> |
| In reply to | #100873 |
On Tue, Jul 27, 2021 at 02:13:33PM +0200, Andreas Metzler wrote:
> On 2021-07-27 Wouter Verhelst <wouter@debian.org> wrote:
> > On Thu, Jul 22, 2021 at 03:20:05PM +0100, Simon McVittie wrote:
> >> On Thu, 22 Jul 2021 at 15:53:32 +0200, Wouter Verhelst wrote:
> >>> I've suggested previously that we can easily make it RC for bookworm to
> >>> have a file outside a limited set of directories (/etc and /usr would be
> >>> OK, but notably /bin /lib and /sbin wouldn't be) that is not a symlink.
> >>> This is easy to detect with a lintian check and reasonably easy to
> >>> implement
>
> >> I don't think that works in general without breaking some of Debian's
> >> axioms around Essential packages, as previously described here:
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636#118
>
> > Yes. Those arguments didn't convince me then, and they don't convince me
> > now.
>
> > A package in the essential set could work around the issue by moving a
> > file around and creating a necessary symlink in preinst rather than
> > shipping things. The set of Essential packages is small however, and
> > most packages can ship a compat symlink.
>
> > I didn't say we *should* ship compat symlinks; I said we should make
> > antyhing that is *not* a compat symlink in a particular set of
> > directories be RC.
> [...]
>
> Hello Wouter,
>
> I will bite.
Cool.
> just for context: Simon said in #978636 that e.g. coreutils
> a) cannot ship both /usr/bin/mv and /bin/mv (the latter a symlink) in
> the tarfile since /bin _might_ be a symlink to /usr/bin but
> b) it needs to provide /bin/mv in unpacked, unconfigured state.
>
> Simon then said we needed a flag day where the aliasing-symlinks /bin -->
> /usr/bin are either guaranteed to exist or forbidden. Once that is know
> essential packages either ship both /usr/bin/mv and /bin/mv (the latter
> a symlink) or only ship /usr/bin/mv (with no symlink required.)
>
> Afaiu you are suggesting to do somethink like this instead and
> immediately post bulleye release.
> ----------------------------------------
> preinst upgrade|install
> if aliasing-symlinks /bin --> /usr/bin
> # do nothing
> else
> mv /bin/mv /usr/bin/mv
That should be a copy (mv is too dangerous)
> ln -s /usr/bin/mv /bin/mv
This can be "ln -sf" to make it atomic.
> fi
> Plus corresponding error handling code in postrm abort install.
> ----------------------------------------
Yes, but for packages in the Essential set only. For other packages, we
can make it much simpler.
> I just do not get the benefit. It seems rather complicated with
> potential for breakage in corner cases and unnecessary since we (CTTE)
> have essentially decided that there is going to be a cutoff date
> pre-bookworm-release whereupon package maintainers can rely on the
> existence of aliasing-symlinks and can simply move the file without any
> maintainerscripts. It seems to be a waste of work to write
> complicated maintainerscripts that are only needed as long as we need to
> handle both usrmerge-d and non-usrmerge-d systems.
I'm not worried about the support for both usrmerge'd and not usrmerge'd
systems.
I'm worried about systems being written to completely bypass the dpkg
database. It's being pushed forward "because we broke things in the past
and now the only way to fix it is to break even more things". That's BS.
I'm convinced there is a way that we can move forward which does *not*
require bypassing the dpkg database. I think that such a way *should* be
preferential, and the complete lack of even a desire to discuss things
with the dpkg maintainer in ways that the dpkg maintainer thinks is a
reasonable way forward is distressing for me.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
[toc] | [prev] | [next] | [standalone]
| From | Andrey Rahmatullin <wrar@debian.org> |
|---|---|
| Date | 2021-07-27 16:00 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CFvMJ-4ZL-3@gated-at.bofh.it> |
| In reply to | #100875 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, Jul 27, 2021 at 03:25:48PM +0200, Wouter Verhelst wrote: > I'm worried about systems being written to completely bypass the dpkg > database. Like alternatives and things that create files in postinst? -- WBR, wRAR
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <wouter@debian.org> |
|---|---|
| Date | 2021-07-27 17:10 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CFwSt-5UL-1@gated-at.bofh.it> |
| In reply to | #100876 |
On Tue, Jul 27, 2021 at 06:53:01PM +0500, Andrey Rahmatullin wrote:
> On Tue, Jul 27, 2021 at 03:25:48PM +0200, Wouter Verhelst wrote:
> > I'm worried about systems being written to completely bypass the dpkg
> > database.
> Like alternatives and things that create files in postinst?
The alternatives system doesn't bypass the dpkg database. It creates
extra symlinks on the system that do not exist in the dpkg database.
Creating files in postinst doesn't bypass the dpkg database. It creates
extra files on the system that do not exist in the dpkg database.
Creating a system that tells dpkg that files exist in one place but
where in reality they're in a different place does bypass the dpkg
database.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
[toc] | [prev] | [next] | [standalone]
| From | Sam Hartman <hartmans@debian.org> |
|---|---|
| Date | 2021-07-27 17:30 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CFxbP-61V-1@gated-at.bofh.it> |
| In reply to | #100875 |
[Multipart message — attachments visible in raw view] — view raw
>>>>> "Wouter" == Wouter Verhelst <wouter@debian.org> writes:
Wouter> I'm convinced there is a way that we can move forward which
Wouter> does *not* require bypassing the dpkg database. I think that
Wouter> such a way *should* be preferential, and the complete lack
Wouter> of even a desire to discuss things with the dpkg maintainer
Wouter> in ways that the dpkg maintainer thinks is a reasonable way
Wouter> forward is distressing for me.
Yeah, like extending dpkg to be able to tell dpkg that /bin and /sbin
are aliases and have it deal with that. I think that adding that
extension to dpkg is going to be simpler (technically) than getting the
handling right to move things in essential packages. Your corrections
(copy instead of mv, atomic symlink) are in my mind just the beginning
in terms of how complicated that's going to be. I noticed that neither
of you took a stab at the error handling for abort-upgrade.
We'd either need to do that for each essential package, or try and come
up with something (in debhelper?) that is a useful abstraction. In
practice we'd probably find that we needed a combination.
So, even though I think the extensions to dpkg will also be complicated,
at a purely technical level, I think they are less complicated.
I understand technical complexity is only part of the picture.
I understand the dpkg maintainer might make extending dpkg politically
challenging. I also agree that there are things we could have done
better throughout this process in terms of being respectful in our
decision making, giving people a chance to voice their opinions, but
ultimately letting a decision be made and all falling in on that
decision (or standing aside if we cannot) once that has been done.
I think the areas for improvement in decision making are broad here.
I'll pick examples from both sides.
During the discussion of the debootstrap decision to default to merged
/usr, several people pointed to a debian-devel thread and claimed that
thread came to a consensus in favor of merged /usr.
That was not obvious to me as someone who read the referenced thread.
More over, since no one chose to summarize the discussion, people didn't
have an opportunity to confirm they were on the same page or raise
objections if they felt concerns they raised had not been addressed.
Today though, I think we are approaching (or have passed) a point where
a decision has been made and people need to fall in (or stand aside) and
respect our processes.
If you don't feel that your concerns were adequately addressed, one
constructive thing you can do is help us develop better processes for
the future.
--Sam
[toc] | [prev] | [next] | [standalone]
| From | Steve Cotton <steve@octalot.at> |
|---|---|
| Date | 2021-07-28 02:40 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CFFM5-2Zz-7@gated-at.bofh.it> |
| In reply to | #100881 |
Am Tue, Jul 27, 2021 at 09:23:48AM -0600 schrieb Sam Hartman: > So, even though I think the extensions to dpkg will also be complicated, > at a purely technical level, I think they are less complicated. > > I understand technical complexity is only part of the picture. > I understand the dpkg maintainer might make extending dpkg politically > challenging. I took a look at the changelog and open issues of dpkg. The issues with symlinked dirs were known about 15 years ago. There's a lack of offers of help in those issues, and it seems a lack of volunteers to join the dpkg team. When he says "it would require new *features* to be implemented", I can understand the grumpyness when that means "new features that people have been calling bugs for 15 years, but are still asking when they'll be implemented without helping implement them". I don't know the people in this thread personally, there's surely more that has been said in person. However, just from the debate in this thread and the BTS, it seems the "politics" might be simply be a lack of volunteers compared to demands. Steve
[toc] | [prev] | [next] | [standalone]
| From | Andreas Metzler <ametzler@bebt.de> |
|---|---|
| Date | 2021-07-27 17:40 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CFxlw-65z-7@gated-at.bofh.it> |
| In reply to | #100875 |
On 2021-07-27 Wouter Verhelst <wouter@debian.org> wrote: > On Tue, Jul 27, 2021 at 02:13:33PM +0200, Andreas Metzler wrote: [...] >> Afaiu you are suggesting to do somethink like this instead and >> immediately post bulleye release. >> ---------------------------------------- >> preinst upgrade|install >> if aliasing-symlinks /bin --> /usr/bin >> # do nothing >> else >> mv /bin/mv /usr/bin/mv > That should be a copy (mv is too dangerous) >> ln -s /usr/bin/mv /bin/mv > This can be "ln -sf" to make it atomic. >> fi >> Plus corresponding error handling code in postrm abort install. >> ---------------------------------------- > Yes, but for packages in the Essential set only. For other packages, we > can make it much simpler. >> I just do not get the benefit. It seems rather complicated with >> potential for breakage in corner cases and unnecessary since we (CTTE) >> have essentially decided that there is going to be a cutoff date >> pre-bookworm-release whereupon package maintainers can rely on the >> existence of aliasing-symlinks and can simply move the file without any >> maintainerscripts. It seems to be a waste of work to write >> complicated maintainerscripts that are only needed as long as we need to >> handle both usrmerge-d and non-usrmerge-d systems. > I'm not worried about the support for both usrmerge'd and not usrmerge'd > systems. > I'm worried about systems being written to completely bypass the dpkg > database. Hello Wouter, I think we complicated things enormously and caused real breakage by trying to support both setups. This has already caused considerable work without longterm gain and is preventing us to reach an unbroken state (dpkg knowning the correct paths on all systems) again. That is what I see as goal. The maintainerscript setup for symlinking looks like a lot of work and muddles the whole situation even more, there are more files/symlinks dpkg does not know about and our systems diverge even more. I really do not get how that is a step forward. > It's being pushed forward "because we broke things in the past > and now the only way to fix it is to break even more things". That's BS. [...] When you say "break more things" you are thinking of the social effect (alienating Guillem)? I am not aware of any plans for new technical breakage. cu Andreas PS: As you can probably tell English is not my native language so please take the whole mail with a grain of salt if I did not manage to hit the correct level of politeness. -- `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 | Guillem Jover <guillem@debian.org> |
|---|---|
| Date | 2021-07-27 14:30 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CFunD-4d9-1@gated-at.bofh.it> |
| In reply to | #100872 |
On Tue, 2021-07-27 at 11:44:32 +0200, Wouter Verhelst wrote:
> On Thu, Jul 22, 2021 at 03:20:05PM +0100, Simon McVittie wrote:
> > On Thu, 22 Jul 2021 at 15:53:32 +0200, Wouter Verhelst wrote:
> > > I've suggested previously that we can easily make it RC for bookworm to
> > > have a file outside a limited set of directories (/etc and /usr would be
> > > OK, but notably /bin /lib and /sbin wouldn't be) that is not a symlink.
> > > This is easy to detect with a lintian check and reasonably easy to
> > > implement
> >
> > I don't think that works in general without breaking some of Debian's
> > axioms around Essential packages, as previously described here:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636#118
>
> Yes. Those arguments didn't convince me then, and they don't convince me
> now.
Ack, these are very contrived.
> A package in the essential set could work around the issue by moving a
> file around and creating a necessary symlink in preinst rather than
> shipping things. The set of Essential packages is small however, and
> most packages can ship a compat symlink.
Yes, along those lines. To try to do something resembling dpkg's safe
behavior, we'd need to do in preinst, something like:
- if /usr/foo does not exist:
- copy /foo to /usr/foo
- replace /foo with a symlink to /usr/foo
Then dpkg would replace /usr/foo with the new version. Of course this
is all kinds of suboptimal, as the .debs will still not ship the actual
symlinks and it's trying to replicate what dpkg is designed and supposed
to do to handle Essential packages safely, even when doing this kind of
switch, where it will delay symlink installation as the last step… but
we cannot do that right now due to the incorrect restrictions imposed by
merged-/usr-via-aliased-dirs. :(
I have very deep and strong regrets about having removed compat symlinks
under /, to make it possible for people that wanted to locally use
the usrmerge hack. I guess the lesson learned with this episode, is
that in the future, similar stuff cannot be let through, when people
promise this will not be pushed into the distro, and it's just for
local deployments and similar, or we end up with this kind of mess. :/
> > I have a longer mail written with possible ways forward, which I'm
> > deliberately not sending right now, because the first step in all of these
> > plans is "release Debian 11" and I don't want to distract the people who
> > are making that happen (any more than has already happened).
>
> This is so exhausting.
Indeed, very. The impression I'm getting is that instead of stopping the
bleeding effect, this is being let fester to the point any option will
be terrible, so anything, regardless of its badness will seem acceptable
to make progress at that point.
> Yes, I know the release is close, and yes, I know that some people are
> immensely busy working on that. I want to help them do so in any way I
> can, but they're not *required* to read -devel, and "they might read
> this and get distracted" seems like a pretty poor argument.
>
> I'm not busy with the release. Are you? If not, you *can* actually come
> up with an argument right now, and I promise not to insist on any
> decision being made until the release happens, so that those
> hypothetical people who *are* busy with the release can still chip in
> later if they choose to do so.
Yes, I'd say this is one of Debian's development fallacies. You know
you are dealing with strong arguments when this comes up. Also the
proponents are not worried now that this is being shoved down by
force due to the involvement of the TC…
Thanks,
Guillem
[toc] | [prev] | [next] | [standalone]
| From | Simon Richter <sjr@debian.org> |
|---|---|
| Date | 2021-07-27 16:40 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CFwpr-5rM-3@gated-at.bofh.it> |
| In reply to | #100872 |
[Multipart message — attachments visible in raw view] — view raw
Hi,
On 7/27/21 11:44 AM, Wouter Verhelst wrote:
> A package in the essential set could work around the issue by moving a
> file around and creating a necessary symlink in preinst rather than
> shipping things. The set of Essential packages is small however, and
> most packages can ship a compat symlink.
In debootstrap (which is the important use case for Essential packages
and their constraints), all Essential packages are unpacked first, and
then, individually, their preinst is run, the files unpacked again (this
time from dpkg), and then we're in normal dpkg land, although in a chroot.
So the concept of a preinst script for an Essential package is wobbly at
best. For debootstrap --foreign, this might be even more complicated.
Also, take care when moving shell commands from a shell script: the bash
shell at least keeps a cache of commands to paths so it doesn't have to
do a full path search every time. A shell script that calls
mv /bin/cp /usr/bin/cp
ln -s ../usr/bin/cp bin/cp
mv /bin/ln /usr/bin/ln
ln -s ../usr/bin/ln bin/ln
could fall over because it cached the location of "ln" as /bin/ln in the
beginning, then after the move cannot find it anymore. That needs at
least a "hash -d ln".
Simon
[toc] | [prev] | [next] | [standalone]
| From | Guillem Jover <guillem@debian.org> |
|---|---|
| Date | 2021-07-27 17:10 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CFwSu-5UL-11@gated-at.bofh.it> |
| In reply to | #100877 |
On Tue, 2021-07-27 at 16:26:34 +0200, Simon Richter wrote: > On 7/27/21 11:44 AM, Wouter Verhelst wrote: > > A package in the essential set could work around the issue by moving a > > file around and creating a necessary symlink in preinst rather than > > shipping things. The set of Essential packages is small however, and > > most packages can ship a compat symlink. > > In debootstrap (which is the important use case for Essential packages and > their constraints), all Essential packages are unpacked first, and then, > individually, their preinst is run, the files unpacked again (this time from > dpkg), and then we're in normal dpkg land, although in a chroot. The installation bootstrap is currently "undefined behavior" and it's not specified by policy. The properties of the Essential set do not apply there. See <https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap>. > So the concept of a preinst script for an Essential package is wobbly at > best. Not really. Bootstrapping has always been done with strings and tape. Of course, having to unnecessarily add more maintainer scripts to handle something that dpkg can do perfectly fine on its own, would regress the progress we have been making to make the installation bootstrapping automatable and definable. But that seems less worse than the breakage induced by the merged-/usr-via-aliased-dirs layout. :/ > For debootstrap --foreign, this might be even more complicated. Only a few paths are expected to be hardcoded, nothing that couldn't be special-cased by debootstrap along all other bootstrapping knowledge it contains which would ideally be contained in their respective packages anyway. But this indeed is, having to pile hack over hack from the original broken foundation. > Also, take care when moving shell commands from a shell script: the bash > shell at least keeps a cache of commands to paths so it doesn't have to do a > full path search every time. A shell script that calls > > mv /bin/cp /usr/bin/cp > ln -s ../usr/bin/cp bin/cp > mv /bin/ln /usr/bin/ln > ln -s ../usr/bin/ln bin/ln > > could fall over because it cached the location of "ln" as /bin/ln in the > beginning, then after the move cannot find it anymore. That needs at least a > "hash -d ln". As has been mentioned, this is completely unsafe and does not map to what dpkg would be doing. Regards, Guillem
[toc] | [prev] | [next] | [standalone]
| From | Calum McConnell <calumlikesapplepie@gmail.com> |
|---|---|
| Date | 2021-07-27 19:30 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CFz3X-7g5-3@gated-at.bofh.it> |
| In reply to | #100879 |
[Multipart message — attachments visible in raw view] — view raw
> Of course, having to unnecessarily add more maintainer scripts to
> handle something that dpkg can do perfectly fine on its own
TL;DR: merged-usr-via-symlink-farms cannot be done without changing dpkg,
and since the quote above seems to indicate you'd be willing to do that,
why not just change dpkg to support aliased dirs?
--------------------
Lets look at going forward. We have a problem (Debian supports a mixture
of merged-usr and unmerged-usr layouts). We need to solve this problem,
since the headaches it produces are far worse than either layout on its
own. Let's assume the eventual solution is going to be merged-usr:an
Fact: A significant portion of supported Debian installations currently
use usrmerge, with symlinks between /bin -> /usr/bin, /lib -> /usr/lib,
etc
Any path forward must allow for that. The decisions that caused that fact
to be true are irrelevant: whether or not that fact is a good or bad thing
doesn't matter. What matters is that it is true, and so we need to work
around it, even if the path forward we choose involves reverting it.
It doesn't matter if merged-usr-via-aliased-dirs would have been better if
we'd just done it from the start. It doesn't matter if we could have made
that transition with a small change to debhelper and a release cycle. It
doesn't even matter if the problems we are facing now would never have
occurred with that plan. The fact is true: systems using merged-usr-via-
aliased-dirs exist, and we need to figure out how to go onwards from here.
One way to move forward despite that fact is to mandate running dpkg-fsys-
usrunmess on every system that has a merged-usr layout, and then move
forward from there. However, that script is hardly battle-tested, and
that solution is completely unacceptable to usrmerge proponents. So lets
look at other solutions that would work for everyone.
Another way forward is to transition existing systems without merged-usr
to a merged-usr-via-symlink-farms. To accomplish this, we need the
ability to create symlinks in installations that are not usrmerge, but to
not create those links in installations that are. That requires either
maintainer scripts or a change to dpkg. You just criticized maintainer
scripts, so I would assume that they are not your favorite solution.
Furthermore, others have pointed out that essential packages need to work
before maintainer scripts are executed. This behavior is codified in
policy:
> "Since dpkg will not prevent upgrading of other packages while an essential package is in an unconfigured state, all essential packages must supply all of their core functionality even when unconfigured".
In other words, using maintainer scripts to create the symlinks that
enable the core functionality of these packages during configuration is a
no-go without a revision to policy and a change to dpkg (which might be
impossible). That means the symlinks would need to be included in the
package declaratively: but simply shipping them would break the existing
merged-usr installations. We've already established that un-merging and
then re-merging every installation isn't going to happen: so we'll need to
get the file references in place using a method that isn't shipping two
aliasing files and doesn't require maintainer scripts.
Now, shipping the file in /bin, and then eventually moving it to /usr/bin
and replacing it with a symlink as soon as you can would work, but that
isn't a solution. It means that we will always have packages that ship
files in /bin, because there is no migration path out of that, short of
completely redefining 'essential'. In thirty years, the bash package will
still contain this cludge. That is not a suitable long term solution, and
I think you agree.
Simply modifying dpkg to automatically produce symlinks from /bin to
/usr/bin at unpack time is not enough either: dpkg isn't necessarily the
tool doing the unpacking, and so other tools would need to be modified,
each one of them checking for a merged-usr and then accounting for it if
needed. This solution is actually viable: it would lead to a working
system, and not break the essential guarantee.
However...
Achieving this would require changing every tool that is responsible for
unpacking a Debian package. That isn't just dpkg and debootstrap: there
are many others. mmdebstrap and cdeboostrap come to mind. This approach
thus requires significant changes to at least four distinct tools. It
would also require at least two upgrade cycles before maintainers could
actually rely on the system being merged-usr: one cycle to get the dpkg
change out, and another to ensure that all packages have been changed to
ship their files in /usr. That is four years of waiting.
Of course, one could drop that to two years if you made the dpkg change a
little bit more aggressive. Since we already have dpkg creating
compatibility symlinks, why not have it also handle the file move? Simply
treat all files shipped to /{bin,sbin,lib} as actually being shipped to
/usr/{bin,sbin,lib}, and create symlinks accordingly. But that raises an
important question.
If we are willing to do that, why not just tweak dpkg to support merged-
usr-via-aliased-dirs? As far as I can tell, the problems with the layout
boil down to "we're letting packages treat the folders as separate, but in
the layout they aren't". Since we are already changing dpkg to make it
treat the folders as equivalent (which we need to do to avoid a long and
painful upgrade cycle), why not just save a few hundred symlinks and use
the aliased-dirs layout?
Thanks for making it through my castle of text,
Calum McConnell
[toc] | [prev] | [next] | [standalone]
Page 3 of 13 — ← Prev page 1 2 [3] 4 5 … 13 Next page →
Back to top | Article view | linux.debian.devel
csiph-web