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 2 of 13 — ← Prev page 1 [2] 3 4 … 13 Next page →
| From | Gunnar Wolf <gwolf@debian.org> |
|---|---|
| Date | 2021-07-19 09:00 +0200 |
| Message-ID | <CCvpT-8uZ-1@gated-at.bofh.it> |
| In reply to | #100808 |
[Multipart message — attachments visible in raw view] — view raw
As I said, on a separate mail... Marc Haber dijo [Mon, Jul 19, 2021 at 07:12:24AM +0200]: > In an ideal world, would the package manager not be a service utility > to SUPPORT policy and adapt to changing environment contitions instead > being a showstopper for innovation? > > Who is the dpkg maintainer to challenge the decisions of the entire > project? I fully understand that there is only ONE dpkg maintainer, > but a utility THIS central to the entire ecosystem not being team > maintained is a HUGE part of the problem. > > And no, I cannot help and no, you wouldn't want me to write a single > line of code in a package THIS central. > (...) > Would it not be dpkg's job to work around these flaws? It's not that > every other component of a Debian system are perfect. FWIW, I mostly agree with what you say here -- If the project decides to a new standard (and, in this case, it has via the TC's decision -- which can of course be repealed by GR, if things come to that), packages that behave differently... are buggy and should be fixed. Of course, dpkg is a very special case for obvious reasons; I did try to reach out to Guillem when we started discussing the bug at the TC, and was disheartened by his harsh reply basically negating all possibility of discussion because his non-belief in the TC itself. There are technical issues that this migration will bring, and yes, there is a nonzero chance some users will be bitten by the dissonance between dpkg and reality. But after two TC bug resolutions (#914897 and #978636), and after lots of bytes have been spilled by various people, I can only see work has to be put into making possibly problematic cases less likely -- rebuilding and checking packages don't ship files in the root directories will cover a great deal of the distance. If aliasing the directories via symlinks is so messy, well... we should focus on the root cause, and fix the rasons for it to be broken as much as we can. The symlinks could probably be an unconsequential footnote if this is done right.
[toc] | [prev] | [next] | [standalone]
| From | Stephan Lachnit <stephanlachnit@debian.org> |
|---|---|
| Date | 2021-07-19 11:40 +0200 |
| Subject | Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) |
| Message-ID | <CCxUJ-1DY-5@gated-at.bofh.it> |
| In reply to | #100805 |
On Mon, Jul 19, 2021 at 3:37 AM Guillem Jover <guillem@debian.org> wrote: > 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, if it had not been for the mess required > by merged-usr-via-aliased-dirs. :/ Maybe I get this wrong, but I don't think this conflicts with the decision from the TC. Until Debian 12 gets released, we have a lot of time for a transition. Maybe we should start discussing the transition and less whether or not we do it, as this has been decided now anyway. We could start with collecting the packages that install to /bin* instead of /usr/bin, and adjust the packaging so that they don't do that. Of course, we would need to add a maintainer script that detects un-merged usr and creates a symlink. Actually, I think it would be enough to just let debhelper detect if a package installs to /bin, and adjust the package automatically. For packages not using debhelper, lintian can add a warning if the package installs to /bin. After all packages that installed to /bin have been rebuilt, nothing would install to /bin except for symlinks. At this point, it shouldn't matter if you run a merged usr system or not, or am I forgetting something? IMHO it would make way more sense to discuss how to merge usr once the packages are fixed. Anyway, I think the discussion made clear that we shouldn't immediately start with merging usr once bullseye is released, and I wouldn't interpret the TC decision as such. Regards, Stephan * using /bin as an example, same goes for /lib etc
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2021-07-19 13:00 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CCza9-2nN-1@gated-at.bofh.it> |
| In reply to | #100814 |
On Mon, 19 Jul 2021 at 11:33:49 +0200, Stephan Lachnit wrote:
> We could start with collecting the packages that install to /bin*
> instead of /usr/bin, and adjust the packaging so that they don't do
> that. [...] At this point, it shouldn't
> matter if you run a merged usr system or not, or am I forgetting
> something?
This would have part of the practical effect of merged-/usr, but not all
of it. It could still be a useful step forwards, but we should not view
it as being entirely equivalent to merged-/usr.
What we have now on unmerged-/usr systems, using /bin/bash and
/usr/bin/perl as examples of Essential programs that use the two paths:
bash perl
/bin/foo physical location (does not exist)
/usr/bin/foo (does not exist) physical location
What we would have on unmerged-/usr systems if we do as you suggest:
bash perl
/bin/foo exists via symlinks (does not exist)
/usr/bin/foo physical location physical location
Merged-/usr for comparison:
bash perl
/bin/foo exists via symlinks exists via symlinks
/usr/bin/foo physical location physical location
As you can see from those tables, a package that hard-codes /usr/bin/bash
is currently considered broken, but would work with either your proposal
or merged-/usr. Conversely, a package that hard-codes /bin/perl would
still be considered broken, would *not* work with your proposal, but
would work on merged-/usr systems.
(Obviously the same applies when considering hard-coded paths in /sbin,
/lib, etc. instead of /bin, in particular the ELF interpreters like
/lib64/ld-linux-x86-64.so.2 that are hard-coded into every
dynamically-linked executable)
Meanwhile, various shared libraries are also moving from /lib to
/usr/lib. One potentially serious problem with that on non-merged-/usr
systems is that we still don't understand why the bugs discussed
in https://bugs.debian.org/911225 and https://bugs.debian.org/949395
happened, and a similar thing could potentially happen to /lib libraries
other than GLib. The script that GLib uses to work around this is generic,
and could be used in other affected packages if required, but it's larger
and more fragile than I'm really comfortable with.
(Merged-/usr systems cannot suffer from bugs like the ones discussed in
#911225, because the paths involved are the same directory.)
smcv
[toc] | [prev] | [next] | [standalone]
| From | Michael Biebl <biebl@debian.org> |
|---|---|
| Date | 2021-07-19 15:30 +0200 |
| Message-ID | <CCBvj-3U7-3@gated-at.bofh.it> |
| In reply to | #100805 |
[Multipart message — attachments visible in raw view] — view raw
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. 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. 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. As Luca pointed out, even distros with a much stricter governance model were not able to do that. The /usr-merge transition as described and decided on in the TC bug, seems to me is the only viable way forward. 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. 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)/. Regards, Michael [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858331#33
[toc] | [prev] | [next] | [standalone]
| From | Johannes Schauer Marin Rodrigues <josch@debian.org> |
|---|---|
| Date | 2021-07-19 16:50 +0200 |
| Subject | Re: merged /usr considered harmful (was Re: Bits from the Technical Committee) |
| Message-ID | <CCCKJ-4ya-1@gated-at.bofh.it> |
| In reply to | #100817 |
[Multipart message — attachments visible in raw view] — view raw
Quoting Michael Biebl (2021-07-19 15:10:42)
> 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.
> 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.
>
> 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.
more precisely, on amd64 unstable:
/bin 247 files
/lib{32,64,x32} 83 files
/lib/firmware 2379 files
/lib/live 115 files
/lib/modules 17500 files
/lib/systemd 2221 files
/lib/udev 614 files
/lib/x86_64-linux-gnu 343 files
/lib/* 441 files
/sbin 547 files
So most files come from /lib/modules, where only 14 packages are involved,
/lib/systemd which will be fixed by an update to dh_installsystemd, and
/lib/firmware where only 36 packages are involved. The remainder then doesn't
sound so scary anymore as it only involves 656 unique packages and not 1747.
And again many of those remaining packages will be fixed by an update to
debhelper, correct? Given that 90% of source packages use dh, that would reduce
the number to a very manageable size.
> There are *many* such entangled transitions
> hidden in there, so I fear this is not manageable.
> As Luca pointed out, even distros with a much stricter governance model
> were not able to do that.
>
> The /usr-merge transition as described and decided on in the TC bug,
> seems to me is the only viable way forward.
>
> 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.
>
> 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)/.
So what what is actually the roadmap after the bullseye release? What is the
way forward? Should I rather file bugs with patches against individual packages
to move their files from /(sbin|bin|lib)/ to /usr/(sbin|bin|lib)/ or do we
already have a debhelper patch to do that move for us?
This would mean that we only have to bear with the problems mentioned by
guillem until that move is complete, correct?
And another question: once there are no more files shipped by any package in
/(sbin|bin|lib)/ we can let base-file create the symlinks?
Thanks!
cheers, josch
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2021-07-19 19:50 +0200 |
| Subject | Re: merged /usr |
| Message-ID | <CCFyV-6hp-3@gated-at.bofh.it> |
| In reply to | #100818 |
On Mon, 19 Jul 2021 at 16:41:42 +0200, Johannes Schauer Marin Rodrigues wrote:
> Should I rather file bugs with patches against individual packages
> to move their files from /(sbin|bin|lib)/ to /usr/(sbin|bin|lib)/
As discussed in previous iterations of the ongoing merged-/usr megathread,
I don't think this can be the whole solution, because some packages have
paths outside /usr that are part of their Essential functionality.
Prominent examples include /bin/bash and /lib64/ld-linux-x86-64.so.2.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636#118 for
full details.
smcv
[toc] | [prev] | [next] | [standalone]
| From | Niels Thykier <niels@thykier.net> |
|---|---|
| Date | 2021-07-20 08:20 +0200 |
| Message-ID | <CCRgK-58z-3@gated-at.bofh.it> |
| In reply to | #100818 |
Johannes Schauer Marin Rodrigues:
> Quoting Michael Biebl (2021-07-19 15:10:42)
>> [...]
>>
>> 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.
>
> more precisely, on amd64 unstable:
>
> /bin 247 files
> /lib{32,64,x32} 83 files
> /lib/firmware 2379 files
> /lib/live 115 files
> /lib/modules 17500 files
> /lib/systemd 2221 files
> /lib/udev 614 files
> /lib/x86_64-linux-gnu 343 files
> /lib/* 441 files
> /sbin 547 files
>
> So most files come from /lib/modules, where only 14 packages are involved,
and debhelper's dh_installmodules that will need to be tweaked to look
into /usr/lib/modules as well.
But I have no idea if/when we would be ready for that and I will not
be changing debhelper until we are ready to move these bits to /usr.
Likewise for udev, here dh_installudev still uses /lib/udev and will
continue to do so until I know that udev also checks /usr/lib/udev.
If you are involved in udev or/and /lib/modules and know that they are
ready to move to the relevant directory under /usr, then please feel
free to file a bug against debhelper requesting that the /usr directory
will be used in the future.
Please do also note in that bug report whether you also want debhelper
to automatically migrate existing files from /lib to /usr/lib. This
should only be the case where we expect (almost) zero breakage from an
automatic "unordered" transition.
(NB: Please use a bug report as I will first be implementing this after
the bullseye release and rely to this thread is likely to be lost in my
inbox)
> /lib/systemd which will be fixed by an update to dh_installsystemd, and
Indeed, I have heard this request and the systemd maintainers confirmed
to me that systemd in bullseye checks both /lib/systemd and
/usr/lib/systemd.
I have a branch lying around trying to support this. The main key
feature missing is the migration of /lib/systemd -> /usr/lib/systemd
(which needs to handle that both exist and merge them into one somehow).
> /lib/firmware where only 36 packages are involved. The remainder then doesn't
> sound so scary anymore as it only involves 656 unique packages and not 1747.
> And again many of those remaining packages will be fixed by an update to
> debhelper, correct? Given that 90% of source packages use dh, that would reduce
> the number to a very manageable size.
>
Indeed, about 90% of all packages uses dh according to trends.
Though for good measure I thought I would explicitly answer the proposal
(from another mail in this thread) that debhelper could move everything
from /lib to /usr/lib:
No, I will not support an unconditional move from /lib to /usr/lib
via debhelper during bookworm.
There are already two distinct examples in this thread for how this
could break things. I will be sticking to "targeted" migrations where
the major consumers have informed me that they are ready to support the
migration.
>> [...]
>>
>> 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)/.
>
> So what what is actually the roadmap after the bullseye release? What is the
> way forward? Should I rather file bugs with patches against individual packages
> to move their files from /(sbin|bin|lib)/ to /usr/(sbin|bin|lib)/ or do we
> already have a debhelper patch to do that move for us?
>
For some, debhelper will your problem but there will packages that will
need manual migration. As I see it, there will *not* be "the debhelper
patch to fix them all" - even if there will /some/ debhelper patchers
that will fix "most of them".
Related, I have no intention of supporting / maintaining a rewrite of
"--prefix/PREFIX" parameters to configure/make/cmake or whatever. (Not
saying anyone proposed it - but mentioning it as another "there will
definitely be manual clean up" data point).
~Niels
[toc] | [prev] | [next] | [standalone]
| From | Guillem Jover <guillem@debian.org> |
|---|---|
| Date | 2021-07-20 11:40 +0200 |
| Message-ID | <CCUoi-76d-5@gated-at.bofh.it> |
| In reply to | #100818 |
On Mon, 2021-07-19 at 16:41:42 +0200, Johannes Schauer Marin Rodrigues wrote: > So what what is actually the roadmap after the bullseye release? What is the > way forward? Should I rather file bugs with patches against individual packages > to move their files from /(sbin|bin|lib)/ to /usr/(sbin|bin|lib)/ or do we > already have a debhelper patch to do that move for us? Unfortunately, when the supporters of the merged-/usr-via-aliased-dirs pushed their approach into the distribution, that meant that package stopped being able to ship compatibility symlinks under «/», and those needed to be "handled" in maintscripts (by reimplementing poorly and unsafely what dpkg is supposed to do). This means dpkg is not in the loop and cannot perform a safe upgrade moving these pathnames safely, as long as merged-/usr-via-aliased-dirs is supported. This is all kinds of nasty, because a proposal that has a complete disregard for the packaging system, and is founded on assumptions about features that do not even exist, is also forcing that design breakage into a solution that would otherwise require no such hacks. :( > This would mean that we only have to bear with the problems mentioned by > guillem until that move is complete, correct? No. Even if today we magically could get all .debs shipping object directly under «/usr» instead of «/», and had the aliased symlinks in place, the problems I've mentioned would pretty much be in place. Regards, Guillem
[toc] | [prev] | [next] | [standalone]
| From | Guillem Jover <guillem@debian.org> |
|---|---|
| Date | 2021-07-20 12:30 +0200 |
| Message-ID | <CCVaF-7B8-1@gated-at.bofh.it> |
| In reply to | #100831 |
On Tue, 2021-07-20 at 11:31:37 +0200, Guillem Jover wrote: > Unfortunately, when the supporters of the merged-/usr-via-aliased-dirs > pushed their approach into the distribution, that meant that package > stopped being able to ship compatibility symlinks under «/», and those > needed to be "handled" in maintscripts (by reimplementing poorly and > unsafely what dpkg is supposed to do). This means dpkg is not in the > loop and cannot perform a safe upgrade moving these pathnames safely, > as long as merged-/usr-via-aliased-dirs is supported. Sorry, how sloppy of me, let me qualify that last word, to avoid any confusion, "supported". As in inflicting that into unsuspecting users, and in having to bear and pay the price for its current existence, not as in an approach that is supported by the packaging system. Regards, Guillem
[toc] | [prev] | [next] | [standalone]
| From | Andreas Metzler <ametzler@bebt.de> |
|---|---|
| Date | 2021-07-20 14:00 +0200 |
| Message-ID | <CCWzM-8i4-1@gated-at.bofh.it> |
| In reply to | #100831 |
On 2021-07-20 Guillem Jover <guillem@debian.org> wrote: > On Mon, 2021-07-19 at 16:41:42 +0200, Johannes Schauer Marin Rodrigues wrote: >> So what what is actually the roadmap after the bullseye release? >> What is the way forward? Should I rather file bugs with patches >> against individual packages to move their files from >> /(sbin|bin|lib)/ to /usr/(sbin|bin|lib)/ or do we already have a >> debhelper patch to do that move for us? > Unfortunately, when the supporters of the merged-/usr-via-aliased-dirs > pushed their approach into the distribution, that meant that package > stopped being able to ship compatibility symlinks under «/», and those > needed to be "handled" in maintscripts (by reimplementing poorly and > unsafely what dpkg is supposed to do). This means dpkg is not in the > loop and cannot perform a safe upgrade moving these pathnames safely, > as long as merged-/usr-via-aliased-dirs is supported. [...] Hello, Isn't this kind of crying over spilt milk? I also wish we never had ended up with the buster/bullseye state where both unmerged and merged-/usr-via-aliased-dirs are fully supported. However there is now a huge number of merged-/usr-via-aliased-dirs installations out there and we cannot make them magically disappear. Undoing merged-/usr-via-aliased-dirs would be very error-prone while afaiui we have a relatively simple plan to get a clean merged /usr in bookworm or bookworm +1: 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. 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 | Svante Signell <svante.signell@gmail.com> |
|---|---|
| Date | 2021-07-20 14:50 +0200 |
| Message-ID | <CCXm9-n7-1@gated-at.bofh.it> |
| In reply to | #100833 |
On Tue, 2021-07-20 at 13:41 +0200, Andreas Metzler wrote: > > Hello, > Isn't this kind of crying over spilt milk? I also wish we never had > ended up with the buster/bullseye state where both unmerged and > merged-/usr-via-aliased-dirs are fully supported. However there is > now a huge number of merged-/usr-via-aliased-dirs installations out > there and we cannot make them magically disappear. Undoing > merged-/usr-via-aliased-dirs would be very error-prone while afaiui > we have a relatively simple plan to get a clean merged /usr in > bookworm or bookworm +1: 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 I for one will always use that whenever I (accidentally?) install Debian in the future. All my old installations does not carry this bug. Or is there some easier way to avoid merged-/usr except using --no- merged-usr in debootstrap with new installations as written in https://wiki.debian.org/Teams/Dpkg/MergedUsr?
[toc] | [prev] | [next] | [standalone]
| From | Polyna-Maude Racicot-Summerside <debian@polynamaude.com> |
|---|---|
| Date | 2021-07-20 21:40 +0200 |
| Message-ID | <CD3KV-4ob-1@gated-at.bofh.it> |
| In reply to | #100834 |
[Multipart message — attachments visible in raw view] — view raw
Hi, On 2021-07-20 3:30 p.m., Marc Haber wrote: > 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. > I think that the option "usrunmess" says pretty much the state of mind regarding the person who named it this way. Something like "usrunmerge" would be more realistic. > Greetings > Marc > -- Polyna-Maude R.-Summerside -Be smart, Be wise, Support opensource development
[toc] | [prev] | [next] | [standalone]
| From | Svante Signell <svante.signell@gmail.com> |
|---|---|
| Date | 2021-07-20 23:20 +0200 |
| Message-ID | <CD5jH-5pd-1@gated-at.bofh.it> |
| In reply to | #100835 |
On Tue, 2021-07-20 at 15:34 -0400, Polyna-Maude Racicot-Summerside wrote: > Hi, > > On 2021-07-20 3:30 p.m., Marc Haber wrote: > > 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. > > > I think that the option "usrunmess" says pretty much the state of > mind regarding the person who named it this way. > > Something like "usrunmerge" would be more realistic. 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?? Or perhaps the Debian project should come to senses with the force of things upon users and developers/maintainers without their approval (consensus-free)? Debian, the Universal Operating System was used some years ago!
[toc] | [prev] | [next] | [standalone]
| From | Holger Levsen <holger@layer-acht.org> |
|---|---|
| Date | 2021-07-21 00:00 +0200 |
| Message-ID | <CD5Wp-5BN-1@gated-at.bofh.it> |
| In reply to | #100837 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, Jul 20, 2021 at 11:15:33PM +0200, Svante Signell wrote: [...] > Debian, the Universal Operating System was used some years ago! Svante, fine. You are unhappy with Debian since years, you're not using it anymore, you are not contributing, this is debian-devel@ not debian-rant@, so please STFU. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The upcoming clima apocalypse is the big elephant in every room now.
[toc] | [prev] | [next] | [standalone]
| From | Svante Signell <svante.signell@gmail.com> |
|---|---|
| Date | 2021-07-21 00:10 +0200 |
| Message-ID | <CD666-5Um-3@gated-at.bofh.it> |
| In reply to | #100838 |
On Tue, 2021-07-20 at 21:51 +0000, Holger Levsen wrote: > On Tue, Jul 20, 2021 at 11:15:33PM +0200, Svante Signell wrote: > [...] > > Debian, the Universal Operating System was used some years ago! > > Svante, fine. You are unhappy with Debian since years, you're not > using it anymore, you are not contributing, this is debian-devel@ not > debian-rant@, so please STFU. Hi Holger, I would have expected a reply like this from you. I do still use Debian, some of my boxes are still Debian-based. Soon they will probably be converted to Devuan though. I do still contribute to Debian, mainly to Debian GNU/Hurd and Debian GNU/kFreeBSD. As long as these ports are still alive within Debian I won't go away. Holger (and others), please consider the arguments and facts given in the latest postings to this thread, these issues are serious and not something you just can easily close with an STFU argument to me! Thanks!
[toc] | [prev] | [next] | [standalone]
| From | Holger Levsen <holger@layer-acht.org> |
|---|---|
| Date | 2021-07-21 00:30 +0200 |
| Message-ID | <CD6ps-60C-7@gated-at.bofh.it> |
| In reply to | #100839 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, Jul 21, 2021 at 12:09:52AM +0200, Svante Signell wrote: > Hi Holger, I would have expected a reply like this from you. I do still > use Debian, some of my boxes are still Debian-based. Soon they will > probably be converted to Devuan though. I do still contribute to > Debian, mainly to Debian GNU/Hurd and Debian GNU/kFreeBSD. ok, cool! & sorry for assuming you didn't contribute! > Holger (and others), please consider the arguments and facts given in > the latest postings to this thread, these issues are serious and not > something you just can easily close with an STFU argument to me! well, sigh, your last mail (to which I replied) was just ranting, which I still think is wrong here. (Once ok, twice too/maybe, ...) however, this ship has sailed, there has been a proper discussion by a proper process and if you don't like it, please start a GR, as this is the way to overrule the TC, if there is a majority for it. writing mails to debian-devel will not change anything. and repeating a discussion every other month without new arguments will just annoy people as one can see here. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Words may inspire but only action creates change.
[toc] | [prev] | [next] | [standalone]
| From | Polyna-Maude Racicot-Summerside <debian@polynamaude.com> |
|---|---|
| Date | 2021-07-21 03:20 +0200 |
| Message-ID | <CD93X-7Ba-1@gated-at.bofh.it> |
| In reply to | #100839 |
[Multipart message — attachments visible in raw view] — view raw
Hi, > Hi Holger, I would have expected a reply like this from you. I do still > use Debian, some of my boxes are still Debian-based. Soon they will > probably be converted to Devuan though. I do still contribute to > Debian, mainly to Debian GNU/Hurd and Debian GNU/kFreeBSD. As long as > these ports are still alive within Debian I won't go away. > I'd love to know more about what made you switch to Devuan and what could I also benefit from using Debian/kFreeBSD. I used to have boxes on FreeBSD long time ago (6.0 I think). Thanks -- Polyna-Maude R.-Summerside -Be smart, Be wise, Support opensource development
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2021-07-21 10:30 +0200 |
| Subject | Re: not actually anything to do with merged-/usr any more |
| Message-ID | <CDfM5-3ep-1@gated-at.bofh.it> |
| In reply to | #100842 |
On Tue, 20 Jul 2021 at 21:16:57 -0400, Polyna-Maude Racicot-Summerside wrote:
> I'd love to know more about what made you switch to Devuan
You're welcome to have this discussion privately, but please take it
off-list. A few days before the provisional release date for Debian 11
is not the time to light more fires on -devel.
Back to the topic of merged-/usr, the first step in any reasonable plan
to move on from the current situation - whether in favour of merged-/usr
or against it - is going to be "get Debian 11 released". So let's do that?
At this point in the release cycle in particular, I would ask anyone
who is not able to contribute directly to getting a high-quality Debian
11 release to contribute by trying not to distract the people who are
making it happen.
Thanks,
smcv
[toc] | [prev] | [next] | [standalone]
| From | Polyna-Maude Racicot-Summerside <debian@polynamaude.com> |
|---|---|
| Date | 2021-07-21 03:20 +0200 |
| Message-ID | <CD93X-7Ba-5@gated-at.bofh.it> |
| In reply to | #100838 |
[Multipart message — attachments visible in raw view] — view raw
Hi, On 2021-07-20 5:51 p.m., Holger Levsen wrote: > On Tue, Jul 20, 2021 at 11:15:33PM +0200, Svante Signell wrote: > [...] >> Debian, the Universal Operating System was used some years ago! > > Svante, fine. You are unhappy with Debian since years, you're not using it > anymore, you are not contributing, this is debian-devel@ not debian-rant@, > so please STFU. > You are so nice with people who have a different opinion than yours. This is really a example of someone who's mature. > -- Polyna-Maude R.-Summerside -Be smart, Be wise, Support opensource development
[toc] | [prev] | [next] | [standalone]
| From | Polyna-Maude Racicot-Summerside <debian@polynamaude.com> |
|---|---|
| Date | 2021-07-21 03:20 +0200 |
| Message-ID | <CD93X-7Ba-3@gated-at.bofh.it> |
| In reply to | #100837 |
[Multipart message — attachments visible in raw view] — view raw
Hi, > 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?? Or > perhaps the Debian project should come to senses with the force of > things upon users and developers/maintainers without their approval > (consensus-free)? > > Debian, the Universal Operating System was used some years ago! > It's really the kind of problem that make Debian look like a crazy non sense operating system. People using program options as a way to shout their opinion to the world... It's a problem with many FOSS project that benefits mainly from volunteer work. Because they need to job done, they can't have any coercion against developer (as a difference, your boss can impose you things). This may be a good thing as it promote creativity and sometime allow emergence of better practice. But in other case, most of the time, it just give a bad look. Reminds me of when I worked with the Tiki CMS project. I was using node with some tools to do pre-processing of JS code and HTML validation. So I added my package.json to the distribution, in case other developer want it. 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. Sometime we also have to accept choices we dislike (hey, we teach this to kids). -- Polyna-Maude R.-Summerside -Be smart, Be wise, Support opensource development
[toc] | [prev] | [next] | [standalone]
Page 2 of 13 — ← Prev page 1 [2] 3 4 … 13 Next page →
Back to top | Article view | linux.debian.devel
csiph-web