Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.devel > #107571 > unrolled thread
| Started by | Helmut Grohne <helmut@subdivi.de> |
|---|---|
| First post | 2023-04-03 14:10 +0200 |
| Last post | 2023-04-24 11:40 +0200 |
| Articles | 20 on this page of 198 — 39 participants |
Back to article view | Back to linux.debian.devel
DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-04-03 14:10 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Raphael Hertzog <hertzog@debian.org> - 2023-04-21 14:20 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <luca.boccassi@gmail.com> - 2023-04-21 16:50 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Simon McVittie <smcv@debian.org> - 2023-04-22 12:50 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <luca.boccassi@gmail.com> - 2023-04-22 14:30 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Sam Hartman <hartmans@debian.org> - 2023-04-26 15:20 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-04-27 00:50 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-04-27 15:40 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg James Addison <jay@jp-hosting.net> - 2023-04-28 16:00 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Jochen Sprickerhof <jspricke@debian.org> - 2023-04-28 19:00 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg James Addison <jay@jp-hosting.net> - 2023-04-28 19:20 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-04-22 13:00 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <luca.boccassi@gmail.com> - 2023-04-22 14:30 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-04-25 21:10 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <bluca@debian.org> - 2023-04-25 22:40 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Raphael Hertzog <hertzog@debian.org> - 2023-04-26 15:20 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Simon Richter <sjr@debian.org> - 2023-04-26 11:20 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <bluca@debian.org> - 2023-04-26 11:40 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Sven Joachim <svenjoac@gmx.de> - 2023-04-26 18:30 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Raphael Hertzog <hertzog@debian.org> - 2023-05-02 12:40 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-05-02 15:00 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Raphael Hertzog <hertzog@debian.org> - 2023-05-03 10:40 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-05-03 12:30 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Simon Richter <sjr@debian.org> - 2023-05-03 20:40 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-05-04 19:20 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Timo Röhling <roehling@debian.org> - 2023-05-05 11:40 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Simon Richter <sjr@debian.org> - 2023-05-05 14:00 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Andreas Metzler <ametzler@bebt.de> - 2023-05-05 18:40 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <bluca@debian.org> - 2023-05-06 00:40 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Simon Richter <sjr@debian.org> - 2023-05-06 07:30 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <bluca@debian.org> - 2023-05-06 14:30 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Simon Richter <sjr@debian.org> - 2023-05-06 17:20 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <bluca@debian.org> - 2023-05-06 18:10 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-05-06 21:00 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <bluca@debian.org> - 2023-05-06 21:50 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Simon McVittie <smcv@debian.org> - 2023-05-06 12:10 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <bluca@debian.org> - 2023-05-06 14:40 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-05-06 21:00 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <bluca@debian.org> - 2023-05-06 23:10 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Sean Whitton <spwhitton@spwhitton.name> - 2023-05-07 01:50 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <bluca@debian.org> - 2023-05-07 13:10 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Sean Whitton <spwhitton@spwhitton.name> - 2023-05-08 20:10 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <bluca@debian.org> - 2023-05-09 03:00 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-05-09 06:20 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <bluca@debian.org> - 2023-05-09 13:10 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-05-07 08:00 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Ansgar <ansgar@43-1.org> - 2023-05-07 09:10 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Ansgar <ansgar@43-1.org> - 2023-05-07 11:20 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <bluca@debian.org> - 2023-05-07 13:10 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Simon Richter <sjr@debian.org> - 2023-05-08 05:00 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <bluca@debian.org> - 2023-05-08 14:00 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Simon Richter <sjr@debian.org> - 2023-05-08 14:20 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Sean Whitton <spwhitton@spwhitton.name> - 2023-05-10 17:40 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Ansgar <ansgar@43-1.org> - 2023-05-10 21:30 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Russ Allbery <rra@debian.org> - 2023-05-10 23:00 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Ansgar <ansgar@43-1.org> - 2023-05-10 23:20 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Russ Allbery <rra@debian.org> - 2023-05-10 23:40 +0200
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Ansgar <ansgar@43-1.org> - 2023-05-11 00:00 +0200
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Ansgar <ansgar@43-1.org> - 2023-05-12 07:50 +0200
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Steve McIntyre <steve@einval.com> - 2023-05-12 10:50 +0200
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-12 12:00 +0200
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Steve McIntyre <steve@einval.com> - 2023-05-12 12:50 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-12 13:00 +0200
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Steve McIntyre <steve@einval.com> - 2023-05-12 13:20 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-12 14:20 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Steve McIntyre <steve@einval.com> - 2023-05-12 16:40 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Holger Levsen <holger@layer-acht.org> - 2023-05-12 16:40 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-12 17:40 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-15 01:30 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Peter Pentchev <roam@ringlet.net> - 2023-05-15 02:10 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-15 02:30 +0200
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Russ Allbery <rra@debian.org> - 2023-05-15 02:20 +0200
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-15 02:50 +0200
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Steve McIntyre <steve@einval.com> - 2023-05-15 03:10 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Bastian Blank <waldi@debian.org> - 2023-05-16 08:50 +0200
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Russ Allbery <rra@debian.org> - 2023-05-15 03:40 +0200
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-15 04:40 +0200
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Russ Allbery <rra@debian.org> - 2023-05-15 17:30 +0200
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-16 03:50 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Russ Allbery <rra@debian.org> - 2023-05-16 05:30 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) James Addison <jay@jp-hosting.net> - 2023-05-16 09:10 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Russ Allbery <rra@debian.org> - 2023-05-16 17:10 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Russ Allbery <rra@debian.org> - 2023-05-16 20:10 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Didier 'OdyX' Raboud <odyx@debian.org> - 2023-05-16 20:10 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-17 01:30 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Russ Allbery <rra@debian.org> - 2023-05-17 02:10 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Andrea Pappacoda <andrea@pappacoda.it> - 2023-05-17 12:50 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Jeremy Stanley <fungi@yuggoth.org> - 2023-05-17 14:20 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Russ Allbery <rra@debian.org> - 2023-05-17 17:00 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-18 00:50 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Russ Allbery <rra@debian.org> - 2023-05-18 01:40 +0200
Standards compliance (Was: Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)) Jeroen Dekkers <jeroen@dekkers.ch> - 2023-05-16 00:50 +0200
What *is* the amd64 ABI Sam Hartman <hartmans@debian.org> - 2023-05-16 05:40 +0200
Re: What *is* the amd64 ABI Russ Allbery <rra@debian.org> - 2023-05-16 05:50 +0200
Re: What *is* the amd64 ABI Michael Hudson-Doyle <michael.hudson@canonical.com> - 2023-05-16 06:50 +0200
Re: What *is* the amd64 ABI Bastien Roucariès <bastien.roucaries@cyu.fr> - 2023-05-20 15:40 +0200
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Steve McIntyre <steve@einval.com> - 2023-05-15 03:00 +0200
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Johannes Schauer Marin Rodrigues <josch@debian.org> - 2023-05-15 07:00 +0200
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Steve McIntyre <steve@einval.com> - 2023-05-15 15:40 +0200
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-15 16:50 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Tzafrir Cohen <tzafrir@cohens.org.il> - 2023-05-16 06:00 +0200
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Simon McVittie <smcv@debian.org> - 2023-05-15 20:40 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Andreas Metzler <ametzler@bebt.de> - 2023-05-12 18:40 +0200
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Simon McVittie <smcv@debian.org> - 2023-05-15 20:00 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-16 04:00 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Simon McVittie <smcv@debian.org> - 2023-05-16 10:30 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Luca Boccassi <bluca@debian.org> - 2023-05-17 01:50 +0200
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) Roger Lynn <Roger@rilynn.me.uk> - 2023-05-18 00:30 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Ansgar <ansgar@43-1.org> - 2023-05-26 08:10 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Matthew Vernon <matthew@debian.org> - 2023-05-26 09:50 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Ansgar <ansgar@43-1.org> - 2023-05-26 10:10 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <bluca@debian.org> - 2023-05-26 10:50 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Matthew Vernon <matthew@debian.org> - 2023-05-26 11:10 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <bluca@debian.org> - 2023-05-07 14:10 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <bluca@debian.org> - 2023-05-07 16:50 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-05-07 23:20 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <bluca@debian.org> - 2023-05-08 03:30 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-05-08 11:00 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <bluca@debian.org> - 2023-05-08 23:40 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <bluca@debian.org> - 2023-05-09 03:10 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Sam Hartman <hartmans@debian.org> - 2023-05-08 21:10 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Russ Allbery <rra@debian.org> - 2023-05-08 22:10 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <bluca@debian.org> - 2023-05-09 03:10 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Sean Whitton <spwhitton@spwhitton.name> - 2023-05-10 17:50 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg RL <richard.lewis.debian@googlemail.com> - 2023-05-13 16:00 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <bluca@debian.org> - 2023-05-13 16:20 +0200
booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Helmut Grohne <helmut@subdivi.de> - 2023-05-17 11:40 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) "G. Branden Robinson" <g.branden.robinson@gmail.com> - 2023-05-17 11:50 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Marco d'Itri <md@Linux.IT> - 2023-05-17 12:20 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Luca Boccassi <bluca@debian.org> - 2023-05-17 12:30 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Sam Hartman <hartmans@debian.org> - 2023-05-17 19:20 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Simon Richter <sjr@debian.org> - 2023-05-18 08:40 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Luca Boccassi <bluca@debian.org> - 2023-05-18 11:30 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Simon Richter <sjr@debian.org> - 2023-05-19 02:40 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Luca Boccassi <bluca@debian.org> - 2023-05-19 13:10 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Sam Hartman <hartmans@debian.org> - 2023-05-17 19:30 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Raphael Hertzog <hertzog@debian.org> - 2023-06-08 10:50 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Luca Boccassi <bluca@debian.org> - 2023-06-08 12:10 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Marco d'Itri <md@Linux.IT> - 2023-06-09 09:50 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Raphael Hertzog <hertzog@debian.org> - 2023-06-09 12:00 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Luca Boccassi <bluca@debian.org> - 2023-06-09 12:40 +0200
Re: booststrapping /usr-merged systems Bjørn Mork <bjorn@mork.no> - 2023-06-09 13:10 +0200
Re: booststrapping /usr-merged systems Marco d'Itri <md@Linux.IT> - 2023-06-09 13:40 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Johannes Schauer Marin Rodrigues <josch@debian.org> - 2023-06-09 17:40 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Helmut Grohne <helmut@subdivi.de> - 2023-06-09 15:30 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Johannes Schauer Marin Rodrigues <josch@debian.org> - 2023-06-09 17:50 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Helmut Grohne <helmut@subdivi.de> - 2023-06-09 18:30 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Richard Laager <rlaager@debian.org> - 2023-06-09 20:10 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Helmut Grohne <helmut@subdivi.de> - 2023-06-09 20:50 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Helmut Grohne <helmut@subdivi.de> - 2023-06-09 22:20 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Jeroen Dekkers <jeroen@dekkers.ch> - 2023-06-11 15:40 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Luca Boccassi <bluca@debian.org> - 2023-06-11 19:10 +0200
Re: booststrapping /usr-merged systems Russ Allbery <rra@debian.org> - 2023-06-11 19:10 +0200
Re: booststrapping /usr-merged systems Luca Boccassi <bluca@debian.org> - 2023-06-11 19:30 +0200
Re: booststrapping /usr-merged systems Russ Allbery <rra@debian.org> - 2023-06-11 20:10 +0200
Re: booststrapping /usr-merged systems Luca Boccassi <bluca@debian.org> - 2023-06-11 20:50 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) HW42 <hw42@ipsumj.de> - 2023-06-09 22:30 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Helmut Grohne <helmut@subdivi.de> - 2023-06-10 07:40 +0200
Re: booststrapping /usr-merged systems Sven Joachim <svenjoac@gmx.de> - 2023-06-10 08:40 +0200
Re: booststrapping /usr-merged systems Sven Joachim <svenjoac@gmx.de> - 2023-06-10 09:00 +0200
Re: booststrapping /usr-merged systems Helmut Grohne <helmut@subdivi.de> - 2023-06-10 10:50 +0200
Re: booststrapping /usr-merged systems Sven Joachim <svenjoac@gmx.de> - 2023-06-10 19:30 +0200
Re: booststrapping /usr-merged systems Luca Boccassi <bluca@debian.org> - 2023-06-10 21:00 +0200
Re: booststrapping /usr-merged systems Timo Röhling <roehling@debian.org> - 2023-06-11 23:20 +0200
Re: booststrapping /usr-merged systems Luca Boccassi <bluca@debian.org> - 2023-06-27 21:50 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Steve McIntyre <steve@einval.com> - 2023-06-09 17:50 +0200
Re: booststrapping /usr-merged systems Bjørn Mork <bjorn@mork.no> - 2023-06-09 20:00 +0200
Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) Simon Richter <sjr@debian.org> - 2023-06-10 04:30 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg David Kalnischkies <david@kalnischkies.de> - 2023-05-03 15:10 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Bastien ROUCARIES <roucaries.bastien@gmail.com> - 2023-04-26 16:50 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-04-27 00:50 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Simon Richter <sjr@debian.org> - 2023-04-27 08:00 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Marc Haber <mh+debian-devel@zugschlus.de> - 2023-04-27 11:00 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-04-27 13:00 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Marco d'Itri <md@Linux.IT> - 2023-04-27 15:40 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Marc Haber <mh+debian-devel@zugschlus.de> - 2023-04-27 18:40 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Russ Allbery <rra@debian.org> - 2023-04-28 21:10 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Holger Levsen <holger@layer-acht.org> - 2023-04-27 14:00 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Simon Richter <sjr@debian.org> - 2023-04-27 17:00 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-04-28 10:10 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <bluca@debian.org> - 2023-04-28 11:40 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Timo Röhling <roehling@debian.org> - 2023-04-28 12:00 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Luca Boccassi <bluca@debian.org> - 2023-04-29 02:50 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Sam Hartman <hartmans@debian.org> - 2023-05-02 17:40 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Simon Richter <sjr@debian.org> - 2023-04-28 14:10 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-04-28 15:50 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Marvin Renich <mrvn@renich.org> - 2023-04-29 20:20 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-04-29 22:20 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-04-28 22:20 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-05-02 15:00 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-05-02 15:10 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-05-02 16:00 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-04-22 13:00 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Raphael Hertzog <hertzog@debian.org> - 2023-04-21 15:10 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Simon Richter <sjr@debian.org> - 2023-04-21 19:30 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Helmut Grohne <helmut@subdivi.de> - 2023-04-22 13:00 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Simon McVittie <smcv@debian.org> - 2023-04-22 15:50 +0200
Re: DEP 17: Improve support for directory aliasing in dpkg Raphael Hertzog <hertzog@debian.org> - 2023-04-24 11:40 +0200
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2023-05-12 12:00 +0200 |
| Subject | Bug#1035904: dpkg currently warning about merged-usr systems (revisited) |
| Message-ID | <GuxJ8-8kU7-1@gated-at.bofh.it> |
| In reply to | #107842 |
On Fri, 12 May 2023 at 09:40, Steve McIntyre <steve@einval.com> wrote: > > On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote: > > > >The core issue as I see it is as follows: > > > >- Debian has decided to support only merged-/usr, including possibly > > moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2 > > as the interpreter in binaries. > > WTF? *Nobody* has been talking about breaking ABI like this, that I've > seen. The interpreter must *not* be changed willy-nilly. Nothing's happening 'willy-nilly'. We are discussing a bunch of seemingly crazy options, as in, "what would _actually_ explode if we do this or do that?", on this very d-devel thread. I posted a longer version here some days ago: https://lists.debian.org/debian-gcc/2023/05/msg00030.html Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Steve McIntyre <steve@einval.com> |
|---|---|
| Date | 2023-05-12 12:50 +0200 |
| Subject | Bug#1035904: dpkg currently warning about merged-usr systems (revisited) |
| Message-ID | <Guyvv-8lq7-11@gated-at.bofh.it> |
| In reply to | #107843 |
On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote: >On Fri, 12 May 2023 at 09:40, Steve McIntyre <steve@einval.com> wrote: >> >> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote: >> > >> >The core issue as I see it is as follows: >> > >> >- Debian has decided to support only merged-/usr, including possibly >> > moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2 >> > as the interpreter in binaries. >> >> WTF? *Nobody* has been talking about breaking ABI like this, that I've >> seen. The interpreter must *not* be changed willy-nilly. > >Nothing's happening 'willy-nilly'. We are discussing a bunch of >seemingly crazy options, as in, "what would _actually_ explode if we >do this or do that?", on this very d-devel thread. I posted a longer >version here some days ago: > >https://lists.debian.org/debian-gcc/2023/05/msg00030.html Oh holy fuck. You're talking about changing ABI by doing this. That *is* utterly crazy. No. -- Steve McIntyre, Cambridge, UK. steve@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2023-05-12 13:00 +0200 |
| Subject | Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) |
| Message-ID | <GuyFc-8lto-9@gated-at.bofh.it> |
| In reply to | #107845 |
On Fri, 12 May 2023 at 11:40, Steve McIntyre <steve@einval.com> wrote: > > On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote: > >On Fri, 12 May 2023 at 09:40, Steve McIntyre <steve@einval.com> wrote: > >> > >> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote: > >> > > >> >The core issue as I see it is as follows: > >> > > >> >- Debian has decided to support only merged-/usr, including possibly > >> > moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2 > >> > as the interpreter in binaries. > >> > >> WTF? *Nobody* has been talking about breaking ABI like this, that I've > >> seen. The interpreter must *not* be changed willy-nilly. > > > >Nothing's happening 'willy-nilly'. We are discussing a bunch of > >seemingly crazy options, as in, "what would _actually_ explode if we > >do this or do that?", on this very d-devel thread. I posted a longer > >version here some days ago: > > > >https://lists.debian.org/debian-gcc/2023/05/msg00030.html > > Oh holy fuck. > > You're talking about changing ABI by doing this. That *is* utterly > crazy. No. It's a thought experiment on a mailing list. If we can't even have those anymore, something went very wrong somewhere. You seem to be aware of things that wouldn't work anymore (I think?). If you have a couple of minutes to spare, may I please ask you to reply to that thread with such examples? I am genuinely interested in understanding and talking about it. Thank you. Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Steve McIntyre <steve@einval.com> |
|---|---|
| Date | 2023-05-12 13:20 +0200 |
| Subject | Bug#1035904: dpkg currently warning about merged-usr systems (revisited) |
| Message-ID | <GuyOR-8lLR-3@gated-at.bofh.it> |
| In reply to | #107845 |
On Fri, May 12, 2023 at 11:40:05AM +0100, Steve McIntyre wrote: >On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote: >>On Fri, 12 May 2023 at 09:40, Steve McIntyre <steve@einval.com> wrote: >>> >>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote: >>> > >>> >The core issue as I see it is as follows: >>> > >>> >- Debian has decided to support only merged-/usr, including possibly >>> > moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2 >>> > as the interpreter in binaries. >>> >>> WTF? *Nobody* has been talking about breaking ABI like this, that I've >>> seen. The interpreter must *not* be changed willy-nilly. >> >>Nothing's happening 'willy-nilly'. We are discussing a bunch of >>seemingly crazy options, as in, "what would _actually_ explode if we >>do this or do that?", on this very d-devel thread. I posted a longer >>version here some days ago: >> >>https://lists.debian.org/debian-gcc/2023/05/msg00030.html > >Oh holy fuck. > >You're talking about changing ABI by doing this. That *is* utterly >crazy. No. People have asked me to expand on this further... I've been involved in defining ABI before, specifically for armhf. It's not a quick and easy process. It needs buy-in from all sides to make things work, and people *really* value the interoperability that it enables. The interpreter path is one of the most important parts of the ABI spec, the bit that makes binaries compatible between all the various stakeholders: compiler/tools people, distros, software vendors, etc. Lots of the rest of the details downstream of this can be changed, and people do this all the time - compare multilib to multi-arch for example. That all works fine *so long as* the runtime linker can be located and started OK. Changing the interpreter path would mean moving to a Debian-specific ABI, breaking that compatibility. Hand-waving that away with (and I quote): "The vast majority of distros today ship the loader in /usr/lib as /lib is just a symlink, so it would be interoperable." is appalling arrogance. No. You do *not* get to break ABI with that argument. The point of the ABI spec is that *everybody* follows it. You don't change it just because you think it'll make your life a little easier when bootstrapping a system. -- Steve McIntyre, Cambridge, UK. steve@einval.com Welcome my son, welcome to the machine.
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2023-05-12 14:20 +0200 |
| Subject | Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) |
| Message-ID | <GuzUB-8mo0-3@gated-at.bofh.it> |
| In reply to | #107847 |
On Fri, 12 May 2023 at 12:08, Steve McIntyre <steve@einval.com> wrote: > > On Fri, May 12, 2023 at 11:40:05AM +0100, Steve McIntyre wrote: > >On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote: > >>On Fri, 12 May 2023 at 09:40, Steve McIntyre <steve@einval.com> wrote: > >>> > >>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote: > >>> > > >>> >The core issue as I see it is as follows: > >>> > > >>> >- Debian has decided to support only merged-/usr, including possibly > >>> > moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2 > >>> > as the interpreter in binaries. > >>> > >>> WTF? *Nobody* has been talking about breaking ABI like this, that I've > >>> seen. The interpreter must *not* be changed willy-nilly. > >> > >>Nothing's happening 'willy-nilly'. We are discussing a bunch of > >>seemingly crazy options, as in, "what would _actually_ explode if we > >>do this or do that?", on this very d-devel thread. I posted a longer > >>version here some days ago: > >> > >>https://lists.debian.org/debian-gcc/2023/05/msg00030.html > > > >Oh holy fuck. > > > >You're talking about changing ABI by doing this. That *is* utterly > >crazy. No. > > People have asked me to expand on this further... > > I've been involved in defining ABI before, specifically for > armhf. It's not a quick and easy process. It needs buy-in from all > sides to make things work, and people *really* value the > interoperability that it enables. > > The interpreter path is one of the most important parts of the ABI > spec, the bit that makes binaries compatible between all the various > stakeholders: compiler/tools people, distros, software vendors, > etc. Lots of the rest of the details downstream of this can be > changed, and people do this all the time - compare multilib to > multi-arch for example. That all works fine *so long as* the runtime > linker can be located and started OK. The loader is still available via the old path, so external/third party/local/other software works unchanged. This should negatively only affect our 1st party packages, when running on a non-merged distro. And are _all_ our packages really 100% compatible with other distros at all? Are they even supposed to be? For example, if I download efibootmgr from Bookworm on an Ubuntu Focal machine, when I try to run it, it fails: root@focal:/tmp# wget http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb --2023-05-12 12:46:17-- http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb Resolving ftp.de.debian.org (ftp.de.debian.org)... 141.76.2.4 Connecting to ftp.de.debian.org (ftp.de.debian.org)|141.76.2.4|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 27572 (27K) [application/vnd.debian.binary-package] Saving to: 'efibootmgr_17-2_amd64.deb' efibootmgr_17-2_amd64.deb 100%[===============================================>] 26.93K --.-KB/s in 0.04s 2023-05-12 12:46:17 (740 KB/s) - 'efibootmgr_17-2_amd64.deb' saved [27572/27572] root@focal:/tmp# dpkg -x efibootmgr_17-2_amd64.deb ebm root@focal:/tmp# ./ebm/bin/efibootmgr ./ebm/bin/efibootmgr: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./ebm/bin/efibootmgr) Should I file a severity: serious bug against efibootmgr because it is not interoperable? The answer is obviously not, because it would be absurd to expect a binary compiled against libraries from one distro to "just work" on an entirely different distro. Glibc itself is not forward compatible, and is allowed to add new symbols, that are not present in older versions, and packages are allowed to depend on them. Aren't those also ABI breakages? What about all the libraries that bump soname? What about binaries that rely on newer kernel interfaces, or IPC interfaces? So, what I am asking is, what actual, real difference does it make if, by default (and with an override available for example), packages built on Debian for Debian record the ld path to point to its (actual) location on Debian, via say a compiler spec file that is injected in a deb build? There very likely is some real difference and impact, and I am genuinely and honestly asking what it could be. If nothing else, it's an interesting topic, even if likely nothing comes out of it. > Changing the interpreter path would mean moving to a Debian-specific > ABI, breaking that compatibility. Hand-waving that away with (and I > quote): > > "The vast majority of distros today ship the loader in /usr/lib as > /lib is just a symlink, so it would be interoperable." > > is appalling arrogance. No. You do *not* get to break ABI with that > argument. The point of the ABI spec is that *everybody* follows > it. You don't change it just because you think it'll make your life a > little easier when bootstrapping a system. AFAIK there are at least 3 distros where the default interpreter path is changed to follow distro-specific customizations: Gentoo, Nix, Guix. So evidently, some people *do* get to "break ABI", and not everybody follows it. So why can't we at least _talk_ about it, pros and cons, advantages and problems, without the tones of the discussion needlessly escalating? Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Steve McIntyre <steve@einval.com> |
|---|---|
| Date | 2023-05-12 16:40 +0200 |
| Subject | Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) |
| Message-ID | <GuC65-8nCA-5@gated-at.bofh.it> |
| In reply to | #107848 |
On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote: >On Fri, 12 May 2023 at 12:08, Steve McIntyre <steve@einval.com> wrote: >> >> On Fri, May 12, 2023 at 11:40:05AM +0100, Steve McIntyre wrote: >> >On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote: >> >>On Fri, 12 May 2023 at 09:40, Steve McIntyre <steve@einval.com> wrote: >> >>> >> >>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote: >> >>> > >> >>> >The core issue as I see it is as follows: >> >>> > >> >>> >- Debian has decided to support only merged-/usr, including possibly >> >>> > moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2 >> >>> > as the interpreter in binaries. >> >>> >> >>> WTF? *Nobody* has been talking about breaking ABI like this, that I've >> >>> seen. The interpreter must *not* be changed willy-nilly. >> >> >> >>Nothing's happening 'willy-nilly'. We are discussing a bunch of >> >>seemingly crazy options, as in, "what would _actually_ explode if we >> >>do this or do that?", on this very d-devel thread. I posted a longer >> >>version here some days ago: >> >> >> >>https://lists.debian.org/debian-gcc/2023/05/msg00030.html >> > >> >Oh holy fuck. >> > >> >You're talking about changing ABI by doing this. That *is* utterly >> >crazy. No. >> >> People have asked me to expand on this further... >> >> I've been involved in defining ABI before, specifically for >> armhf. It's not a quick and easy process. It needs buy-in from all >> sides to make things work, and people *really* value the >> interoperability that it enables. >> >> The interpreter path is one of the most important parts of the ABI >> spec, the bit that makes binaries compatible between all the various >> stakeholders: compiler/tools people, distros, software vendors, >> etc. Lots of the rest of the details downstream of this can be >> changed, and people do this all the time - compare multilib to >> multi-arch for example. That all works fine *so long as* the runtime >> linker can be located and started OK. > >The loader is still available via the old path, so external/third >party/local/other software works unchanged. This should negatively >only affect our 1st party packages, when running on a non-merged >distro. So why the hell do you want to break this in the first place? Does a symlink in the "wrong" place offend you for some reason? For that you want to change a core assumption in *every single binary* in Debian? Believe me, I've been here in the past when we made changes in armhf to accommodate earlier mistakes. That was just for one architecture. What possible benefit do you see in this change? >And are _all_ our packages really 100% compatible with other distros >at all? Are they even supposed to be? > >For example, if I download efibootmgr from Bookworm on an Ubuntu Focal >machine, when I try to run it, it fails: > >root@focal:/tmp# wget >http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb >--2023-05-12 12:46:17-- >http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb >Resolving ftp.de.debian.org (ftp.de.debian.org)... 141.76.2.4 >Connecting to ftp.de.debian.org (ftp.de.debian.org)|141.76.2.4|:80... connected. >HTTP request sent, awaiting response... 200 OK >Length: 27572 (27K) [application/vnd.debian.binary-package] >Saving to: 'efibootmgr_17-2_amd64.deb' > >efibootmgr_17-2_amd64.deb >100%[===============================================>] 26.93K >--.-KB/s in 0.04s > >2023-05-12 12:46:17 (740 KB/s) - 'efibootmgr_17-2_amd64.deb' saved [27572/27572] > >root@focal:/tmp# dpkg -x efibootmgr_17-2_amd64.deb ebm >root@focal:/tmp# ./ebm/bin/efibootmgr >./ebm/bin/efibootmgr: /lib/x86_64-linux-gnu/libc.so.6: version >`GLIBC_2.34' not found (required by ./ebm/bin/efibootmgr) > >Should I file a severity: serious bug against efibootmgr because it is >not interoperable? You're wilfully missing the point, and you know it. >The answer is obviously not, because it would be absurd to expect a >binary compiled against libraries from one distro to "just work" on an >entirely different distro. Glibc itself is not forward compatible, and >is allowed to add new symbols, that are not present in older versions, >and packages are allowed to depend on them. Aren't those also ABI >breakages? What about all the libraries that bump soname? What about >binaries that rely on newer kernel interfaces, or IPC interfaces? > >So, what I am asking is, what actual, real difference does it make if, >by default (and with an override available for example), packages >built on Debian for Debian record the ld path to point to its (actual) >location on Debian, via say a compiler spec file that is injected in a >deb build? >There very likely is some real difference and impact, and I am >genuinely and honestly asking what it could be. If nothing else, it's >an interesting topic, even if likely nothing comes out of it. I have better things to do than argue about this. I refuse to engage with this right now. You're talking about breaking things for *no* discernible benefit that I've seen any discussion about. >> Changing the interpreter path would mean moving to a Debian-specific >> ABI, breaking that compatibility. Hand-waving that away with (and I >> quote): >> >> "The vast majority of distros today ship the loader in /usr/lib as >> /lib is just a symlink, so it would be interoperable." >> >> is appalling arrogance. No. You do *not* get to break ABI with that >> argument. The point of the ABI spec is that *everybody* follows >> it. You don't change it just because you think it'll make your life a >> little easier when bootstrapping a system. > >AFAIK there are at least 3 distros where the default interpreter path >is changed to follow distro-specific customizations: Gentoo, Nix, >Guix. So evidently, some people *do* get to "break ABI", and not >everybody follows it. So why can't we at least _talk_ about it, pros >and cons, advantages and problems, without the tones of the discussion >needlessly escalating? Again: *why* do you want to do this? For all the value here, should we also discuss switching to PE-COFF from ELF for our binaries? That's more commonly used... -- Steve McIntyre, Cambridge, UK. steve@einval.com Is there anybody out there?
[toc] | [prev] | [next] | [standalone]
| From | Holger Levsen <holger@layer-acht.org> |
|---|---|
| Date | 2023-05-12 16:40 +0200 |
| Subject | Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) |
| Message-ID | <GuC65-8nCA-3@gated-at.bofh.it> |
| In reply to | #107849 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, May 12, 2023 at 03:29:29PM +0100, Steve McIntyre wrote: > >> >Oh holy fuck. > So why the hell do you want to break this in the first place? > You're wilfully missing the point, and you know it. > I have better things to do than argue about this. I refuse to engage > with this right now. You're talking about breaking things for *no* > discernible benefit that I've seen any discussion about. language please. and also assume good faith. thanks. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Das Leben ist schön. Von 'einfach' war nie die Rede. (@lernzyklus)
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2023-05-12 17:40 +0200 |
| Subject | Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) |
| Message-ID | <GuD29-8ob1-1@gated-at.bofh.it> |
| In reply to | #107849 |
On Fri, 12 May 2023 at 15:30, Steve McIntyre <steve@einval.com> wrote: > > On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote: > >On Fri, 12 May 2023 at 12:08, Steve McIntyre <steve@einval.com> wrote: > >> > >> On Fri, May 12, 2023 at 11:40:05AM +0100, Steve McIntyre wrote: > >> >On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote: > >> >>On Fri, 12 May 2023 at 09:40, Steve McIntyre <steve@einval.com> wrote: > >> >>> > >> >>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote: > >> >>> > > >> >>> >The core issue as I see it is as follows: > >> >>> > > >> >>> >- Debian has decided to support only merged-/usr, including possibly > >> >>> > moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2 > >> >>> > as the interpreter in binaries. > >> >>> > >> >>> WTF? *Nobody* has been talking about breaking ABI like this, that I've > >> >>> seen. The interpreter must *not* be changed willy-nilly. > >> >> > >> >>Nothing's happening 'willy-nilly'. We are discussing a bunch of > >> >>seemingly crazy options, as in, "what would _actually_ explode if we > >> >>do this or do that?", on this very d-devel thread. I posted a longer > >> >>version here some days ago: > >> >> > >> >>https://lists.debian.org/debian-gcc/2023/05/msg00030.html > >> > > >> >Oh holy fuck. > >> > > >> >You're talking about changing ABI by doing this. That *is* utterly > >> >crazy. No. > >> > >> People have asked me to expand on this further... > >> > >> I've been involved in defining ABI before, specifically for > >> armhf. It's not a quick and easy process. It needs buy-in from all > >> sides to make things work, and people *really* value the > >> interoperability that it enables. > >> > >> The interpreter path is one of the most important parts of the ABI > >> spec, the bit that makes binaries compatible between all the various > >> stakeholders: compiler/tools people, distros, software vendors, > >> etc. Lots of the rest of the details downstream of this can be > >> changed, and people do this all the time - compare multilib to > >> multi-arch for example. That all works fine *so long as* the runtime > >> linker can be located and started OK. > > > >The loader is still available via the old path, so external/third > >party/local/other software works unchanged. This should negatively > >only affect our 1st party packages, when running on a non-merged > >distro. > > So why the hell do you want to break this in the first place? Does a > symlink in the "wrong" place offend you for some reason? For that you > want to change a core assumption in *every single binary* in Debian? > Believe me, I've been here in the past when we made changes in armhf > to accommodate earlier mistakes. That was just for one > architecture. What possible benefit do you see in this change? As it was mentioned on the list, because it makes bootstrapping self-contained, that's a real and concrete benefit that some developers like Helmut care greatly about, and that's why we are talking about it. To me, it sounds very attractive to have a self-contained and canonicalized distro-wide configuration. If the canonical location where certain files are stored in /usr/bin or /usr/lib, it seems sensible to me to configure Debian software to look for it where we actually put it, while maintaining compatibility for external/local software so that it keeps working. And it is also unclear so far what would outright break - the externally defined ABI in terms of where the loader can be accessed at, would still be respected. Hence why questions are being asked. Nobody's being forced to do anything, this is just a discussion. > >And are _all_ our packages really 100% compatible with other distros > >at all? Are they even supposed to be? > > > >For example, if I download efibootmgr from Bookworm on an Ubuntu Focal > >machine, when I try to run it, it fails: > > > >root@focal:/tmp# wget > >http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb > >--2023-05-12 12:46:17-- > >http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb > >Resolving ftp.de.debian.org (ftp.de.debian.org)... 141.76.2.4 > >Connecting to ftp.de.debian.org (ftp.de.debian.org)|141.76.2.4|:80... connected. > >HTTP request sent, awaiting response... 200 OK > >Length: 27572 (27K) [application/vnd.debian.binary-package] > >Saving to: 'efibootmgr_17-2_amd64.deb' > > > >efibootmgr_17-2_amd64.deb > >100%[===============================================>] 26.93K > >--.-KB/s in 0.04s > > > >2023-05-12 12:46:17 (740 KB/s) - 'efibootmgr_17-2_amd64.deb' saved [27572/27572] > > > >root@focal:/tmp# dpkg -x efibootmgr_17-2_amd64.deb ebm > >root@focal:/tmp# ./ebm/bin/efibootmgr > >./ebm/bin/efibootmgr: /lib/x86_64-linux-gnu/libc.so.6: version > >`GLIBC_2.34' not found (required by ./ebm/bin/efibootmgr) > > > >Should I file a severity: serious bug against efibootmgr because it is > >not interoperable? > > You're wilfully missing the point, and you know it. I'm trying to determine where the boundary lies. What are the expectations for interoperability? Are all executables expected to be self-contained? Can they rely on external config that is guaranteed to be there on Debian but not elsewhere? Can they rely on external libraries that are guaranteed to be there on Debian but not elsewhere? Can they rely on external symlinks that are guaranteed to be there on Debian but not elsewhere? How is this all defined, and most importantly, what are the actual use cases being covered? > >The answer is obviously not, because it would be absurd to expect a > >binary compiled against libraries from one distro to "just work" on an > >entirely different distro. Glibc itself is not forward compatible, and > >is allowed to add new symbols, that are not present in older versions, > >and packages are allowed to depend on them. Aren't those also ABI > >breakages? What about all the libraries that bump soname? What about > >binaries that rely on newer kernel interfaces, or IPC interfaces? > > > >So, what I am asking is, what actual, real difference does it make if, > >by default (and with an override available for example), packages > >built on Debian for Debian record the ld path to point to its (actual) > >location on Debian, via say a compiler spec file that is injected in a > >deb build? > >There very likely is some real difference and impact, and I am > >genuinely and honestly asking what it could be. If nothing else, it's > >an interesting topic, even if likely nothing comes out of it. > > I have better things to do than argue about this. I refuse to engage > with this right now. You're talking about breaking things for *no* > discernible benefit that I've seen any discussion about. It is entirely up to you of course, however just saying "things would break" without mentioning what or how does not help to further our understanding of the matter at hand. So far reactions are either one of "what??! weird, but it could actually work!" and "what??! no, because no!". In the absence of somebody explaining "there's use case X that we support as per policy/decision/custom/workflow Y that would break because of Z" I'm finding it very difficult to come to the conclusion that this would actually be problematic, in practice. I am here to be enlightened. > >> Changing the interpreter path would mean moving to a Debian-specific > >> ABI, breaking that compatibility. Hand-waving that away with (and I > >> quote): > >> > >> "The vast majority of distros today ship the loader in /usr/lib as > >> /lib is just a symlink, so it would be interoperable." > >> > >> is appalling arrogance. No. You do *not* get to break ABI with that > >> argument. The point of the ABI spec is that *everybody* follows > >> it. You don't change it just because you think it'll make your life a > >> little easier when bootstrapping a system. > > > >AFAIK there are at least 3 distros where the default interpreter path > >is changed to follow distro-specific customizations: Gentoo, Nix, > >Guix. So evidently, some people *do* get to "break ABI", and not > >everybody follows it. So why can't we at least _talk_ about it, pros > >and cons, advantages and problems, without the tones of the discussion > >needlessly escalating? > > Again: *why* do you want to do this? For all the value here, should we > also discuss switching to PE-COFF from ELF for our binaries? That's > more commonly used... Actually I'd prefer Mach-O - its native graceful support for optional dependencies (dlopen-like) is really nice! But I digress, and "why" is explained above and in earlier mails. Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2023-05-15 01:30 +0200 |
| Subject | Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) |
| Message-ID | <Gvtk5-8WKY-1@gated-at.bofh.it> |
| In reply to | #107848 |
On Sun, 14 May 2023 at 22:37, Josh Triplett <josh@joshtriplett.org> wrote: > > On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote: > > The loader is still available via the old path, so external/third > > party/local/other software works unchanged. This should negatively > > only affect our 1st party packages, when running on a non-merged > > distro. > > And are _all_ our packages really 100% compatible with other distros > > at all? Are they even supposed to be? > > People build things on Debian that are not Debian packages. People > compile binaries on Debian, and expect them to work on any system that > has sufficiently new libraries. > > This is *not* about Debian packages failing to work on other > distributions; this is about *software compiled on Debian* faliing to > work in other environments. Why would "software compiled on Debian" fail to work in other environments? Well, there are many reasons actually, people invented containers/flatpaks/snaps exactly for that reason. But nothing do with anything discussed here though, as far as I can tell? > If you build a dynamically linked binary that only depends on glibc, you > can expect it to be reasonably portable, to any system that uses glibc > and has a sufficiently new version. > > Debian stable is, in fact, one of the common environments people use to > compile binaries for distribution. "sufficiently new version" is doing a lot of work there. We have shlibs dependencies for a reason. In fact, the most common environment used to distribute binaries is the EOL Ubuntu 16.04, slowly switching to the soon-to-be-EOL 18.04. glibc is not forward-compatible, new symbols are added all the time and are used all the time, and you don't jump on a brand new distribution to do that kind of work, that would be self-defeating. > > So, what I am asking is, what actual, real difference does it make if, > > by default (and with an override available for example), packages > > built on Debian for Debian record the ld path to point to its (actual) > > location on Debian, via say a compiler spec file that is injected in a > > deb build? > > Making binaries built *on* Debian different than binaries built *for* > Debian would introduce a needless additional source of complexity, > compared to just compiling code the same way in both cases. That's not how it works today already. There are several significant differences between just running "gcc sources.c" and building a package via debhelper on a buildd, they are not the same thing at all, and they haven't been since forever, there are dozens of compiler/linker options that the Debian package build environment sets. Or will you now also ask the distribution to rollback multiarch, hardening, SOURCE_DATE_EPOCH, -ffile-prefix-map and all the other reproducibility options, and so on? These and many more are all "needless additional sources of complexity, compared to just compiling code the same way" too. Because guess what, there are people who couldn't possibly care less about multiarch/security/reproducibility/etc, and there will also be a subset of users who considers a subset of those compiler options "needless". So are you going to push to have all of that reverted? And also are you going to propose a Policy change that forbids adding any new compiler/linker option to the package build process? > To frame this in different terms: consider that one of the major goals > of systemd has been to harmonize across distributions and eliminate > needless variations that don't serve much actual purpose (e.g. > variations in config file paths for the same config file). Consider how > much effort systemd went to work with distributions, understand and deal > with the *important* variations, and try to convince them to abandon the > *unimportant* variations. Now imagine if someone came along and said > "let's patch systemd to put unit files in /purple/; it'll work with > everything in our distribution". Pretty sure the Nix folks are already doing pretty much that. And if it works for their case, all the power to them. > Or, imagine if someone said "let's inject an argument to gzip, only for > building the .gz files sihpped in our packages of course, to modify the > gzip header and remove a few of the extraneous additional fields; it'll > be fine, because we've patched our gzip to parse it" Not really related, archives are _intended_ to be opened anywhere for any reason. Do you have any actual related use case that would no longer work? Because that would be the easiest and most convincing counter-factual that could be provided. > The x86-64 ABI is set. Feel free to make the case to the next > architecture designer that their new ABI should have the dynamic linker > in `/usr/lib`. That would *not* have the same downsides, as long as > everyone agrees on a path. In practice it is not, though. There are other distributions that change PT_INTERP for their own purposes, they've already been listed in this thread. And I am still not hearing any concrete, factual use case that would be impaired by such a change. I'm beginning to seriously think there aren't any? Is that really the case? Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Peter Pentchev <roam@ringlet.net> |
|---|---|
| Date | 2023-05-15 02:10 +0200 |
| Subject | Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) |
| Message-ID | <GvtWN-8XcJ-1@gated-at.bofh.it> |
| In reply to | #107860 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, May 15, 2023 at 12:24:15AM +0100, Luca Boccassi wrote: > On Sun, 14 May 2023 at 22:37, Josh Triplett <josh@joshtriplett.org> wrote: > > > > On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote: > > > The loader is still available via the old path, so external/third > > > party/local/other software works unchanged. This should negatively > > > only affect our 1st party packages, when running on a non-merged > > > distro. > > > And are _all_ our packages really 100% compatible with other distros > > > at all? Are they even supposed to be? > > > > People build things on Debian that are not Debian packages. People > > compile binaries on Debian, and expect them to work on any system that > > has sufficiently new libraries. > > > > This is *not* about Debian packages failing to work on other > > distributions; this is about *software compiled on Debian* faliing to > > work in other environments. > > Why would "software compiled on Debian" fail to work in other > environments? Well, there are many reasons actually, people invented > containers/flatpaks/snaps exactly for that reason. But nothing do with > anything discussed here though, as far as I can tell? If an ELF executable, compiled on Debian, records its interpreter as /usr/lib/ld-linux.so.2, what happens when one tries to run it on a non-usr-merged system? Even one with a recent enough glibc version? G'luck, Peter -- Peter Pentchev roam@ringlet.net roam@debian.org pp@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2023-05-15 02:30 +0200 |
| Subject | Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) |
| Message-ID | <Gvug9-8Xjm-1@gated-at.bofh.it> |
| In reply to | #107861 |
On Mon, 15 May 2023 at 01:07, Peter Pentchev <roam@ringlet.net> wrote: > > On Mon, May 15, 2023 at 12:24:15AM +0100, Luca Boccassi wrote: > > On Sun, 14 May 2023 at 22:37, Josh Triplett <josh@joshtriplett.org> wrote: > > > > > > On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote: > > > > The loader is still available via the old path, so external/third > > > > party/local/other software works unchanged. This should negatively > > > > only affect our 1st party packages, when running on a non-merged > > > > distro. > > > > And are _all_ our packages really 100% compatible with other distros > > > > at all? Are they even supposed to be? > > > > > > People build things on Debian that are not Debian packages. People > > > compile binaries on Debian, and expect them to work on any system that > > > has sufficiently new libraries. > > > > > > This is *not* about Debian packages failing to work on other > > > distributions; this is about *software compiled on Debian* faliing to > > > work in other environments. > > > > Why would "software compiled on Debian" fail to work in other > > environments? Well, there are many reasons actually, people invented > > containers/flatpaks/snaps exactly for that reason. But nothing do with > > anything discussed here though, as far as I can tell? > > If an ELF executable, compiled on Debian, records its interpreter as > /usr/lib/ld-linux.so.2, what happens when one tries to run it on > a non-usr-merged system? Even one with a recent enough glibc version? This is not about locally built ELF executables, no difference in those. Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2023-05-15 02:20 +0200 |
| Subject | Bug#1035904: dpkg currently warning about merged-usr systems (revisited) |
| Message-ID | <Gvu6t-8Xg0-3@gated-at.bofh.it> |
| In reply to | #107860 |
Luca Boccassi <bluca@debian.org> writes: > Why would "software compiled on Debian" fail to work in other > environments? Well, there are many reasons actually, people invented > containers/flatpaks/snaps exactly for that reason. But nothing do with > anything discussed here though, as far as I can tell? My understanding is that this specific thread is about a mention that we may want to change PT_INTERP to /usr/lib64/ld-linux-x86-64.so.2 or some similar path. If PT_INTERP points to a file that doesn't exist, the program is obviously not going to run. The Linux x86_64 ABI says it must point to /lib64/ld-linux-x86-64.so.2. If we build binaries that use some other value, then we are not building ABI-compliant binaries and they may not run on other systems. This is the whole point of an ABI. An obvious specific example of such a system would be one that didn't merge /usr and thus only had /lib64/ld-linux-x86-64.so.2 and not any other path, but that's just one obvious example. There may be others; the whole point of an ABI is that you do not change things like this, not even if you can't personally imagine why your change wouldn't be harmful. There's a whole process for changing an ABI that involves everyone else agreeing as well, and unless one goes through that process, the ABI is what it is. Debian not building ABI-compliant binaries would be highly surprising. Incidentally, that remains true even if we only do that in distribution packages. I certainly have copied binaries from a Debian package to other Linux systems before for various reasons and expected them to run. Sure, this might not work for other reasons outside of our control, but that's no reason to be gratuitously incompatible by breaking the ABI, particularly for what seem to be annoyances of our own creation with known workarounds. -- Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2023-05-15 02:50 +0200 |
| Subject | Bug#1035904: dpkg currently warning about merged-usr systems (revisited) |
| Message-ID | <Gvuzv-8Xpy-1@gated-at.bofh.it> |
| In reply to | #107862 |
On Mon, 15 May 2023 at 01:14, Russ Allbery <rra@debian.org> wrote: > > Luca Boccassi <bluca@debian.org> writes: > > > Why would "software compiled on Debian" fail to work in other > > environments? Well, there are many reasons actually, people invented > > containers/flatpaks/snaps exactly for that reason. But nothing do with > > anything discussed here though, as far as I can tell? > > My understanding is that this specific thread is about a mention that we > may want to change PT_INTERP to /usr/lib64/ld-linux-x86-64.so.2 or some > similar path. > > If PT_INTERP points to a file that doesn't exist, the program is obviously > not going to run. The Linux x86_64 ABI says it must point to > /lib64/ld-linux-x86-64.so.2. If we build binaries that use some other > value, then we are not building ABI-compliant binaries and they may not > run on other systems. This is the whole point of an ABI. This is not about locally compiled software or such, only packages (and maybe even just a subset of them). > An obvious specific example of such a system would be one that didn't > merge /usr and thus only had /lib64/ld-linux-x86-64.so.2 and not any other > path, but that's just one obvious example. There may be others; the whole > point of an ABI is that you do not change things like this, not even if > you can't personally imagine why your change wouldn't be harmful. There's > a whole process for changing an ABI that involves everyone else agreeing > as well, and unless one goes through that process, the ABI is what it is. > Debian not building ABI-compliant binaries would be highly surprising. That's self-evidently not true, as there are other distributions where that already happens, it's been already mentioned. Besides, we are not talking about sacred religious texts - the point is making things work. If they do, is it _really_ non-compliant/incompatible? > Incidentally, that remains true even if we only do that in distribution > packages. I certainly have copied binaries from a Debian package to other > Linux systems before for various reasons and expected them to run. Sure, > this might not work for other reasons outside of our control, but that's > no reason to be gratuitously incompatible by breaking the ABI, > particularly for what seem to be annoyances of our own creation with known > workarounds. Thanks, that's the first actual real example mentioned so far. And it's an interesting one: taking a $random Debian package and using it on a completely different, non-Debian system. Is that a supported use case? If so, does that mean that I can go ahead and raise a Severity: serious bug on any package that doesn't work in such a way? Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Steve McIntyre <steve@einval.com> |
|---|---|
| Date | 2023-05-15 03:10 +0200 |
| Subject | Bug#1035904: dpkg currently warning about merged-usr systems (revisited) |
| Message-ID | <GvuSR-8XLC-5@gated-at.bofh.it> |
| In reply to | #107864 |
I'm *trying* to assume good faith here, but I'm running out of energy to do so. On Mon, May 15, 2023 at 01:42:27AM +0100, Luca Boccassi wrote: >On Mon, 15 May 2023 at 01:14, Russ Allbery <rra@debian.org> wrote: > >> Incidentally, that remains true even if we only do that in distribution >> packages. I certainly have copied binaries from a Debian package to other >> Linux systems before for various reasons and expected them to run. Sure, >> this might not work for other reasons outside of our control, but that's >> no reason to be gratuitously incompatible by breaking the ABI, >> particularly for what seem to be annoyances of our own creation with known >> workarounds. > >Thanks, that's the first actual real example mentioned so far. And >it's an interesting one: taking a $random Debian package and using it >on a completely different, non-Debian system. Is that a supported use >case? If so, does that mean that I can go ahead and raise a Severity: >serious bug on any package that doesn't work in such a way? Russ has described copying *binaries* out of packages and running them elsewhere. I've done that too, from time to time. This is one of the things made possible by the ABI contract being followed. You are the one proposing to break that contract, thereby *guaranteeing* this will fail on systems where otherwise it could work. I think the onus is on *you* to justify why this is a valid and useful thing to do. Your apparent lack of care for agreed standards here is horrifying. -- Steve McIntyre, Cambridge, UK. steve@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
[toc] | [prev] | [next] | [standalone]
| From | Bastian Blank <waldi@debian.org> |
|---|---|
| Date | 2023-05-16 08:50 +0200 |
| Subject | Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) |
| Message-ID | <GvWFr-9fzZ-5@gated-at.bofh.it> |
| In reply to | #107866 |
Hi Steve On Mon, May 15, 2023 at 02:01:15AM +0100, Steve McIntyre wrote: > Russ has described copying *binaries* out of packages and running them > elsewhere. I've done that too, from time to time. This is one of the > things made possible by the ABI contract being followed. And nothing in that requires that the interpreter matches. Because glibc is clever enough to allow running the interpreter standalone. So in any way you can just call: /lib64/ld-linux-x86-64.so.2 /bin/ls Bastian -- Oh, that sound of male ego. You travel halfway across the galaxy and it's still the same song. -- Eve McHuron, "Mudd's Women", stardate 1330.1
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2023-05-15 03:40 +0200 |
| Subject | Bug#1035904: dpkg currently warning about merged-usr systems (revisited) |
| Message-ID | <Gvvcd-8XSo-3@gated-at.bofh.it> |
| In reply to | #107864 |
Luca Boccassi <bluca@debian.org> writes: > That's self-evidently not true, as there are other distributions where > that already happens, it's been already mentioned. You've mentioned this a couple of times but I don't think I've seen the message where the details were explained. Maybe this was only in your message posted to debian-gcc, which wasn't part of this thread? (It's also possible that I just missed it somewhere.) That message only mentions GUIX, which I don't know very much about, but my recollection (maybe wrong?) is that it's a NIX variant that is doing special tricks to support immutable package trees and roll-forward/roll-back upgrades. I can see why that might be motivation to build incompatible binaries in order to preserve some other invariant they're trying for as the point of their distribution (in particular, I suspect they're pinning binaries to a specific version of the dynamic loader as part of the whole immutable tree strategy). That's a perfectly fine decision in a distribution that's trying to do something very different and is a bit of a science experiment, but I don't think that describes Debian. (Also, no slight on the GUIX folks, but GUIX is not exactly an, uh, major player in Linux distributions, and I'm not sure how much they care about compatibility with anyone else.) > Besides, we are not talking about sacred religious texts - the point is > making things work. If they do, is it _really_ > non-compliant/incompatible? I understand your point in making this argument, but please understand that this sort of willingness to change things if one didn't think they would cause problems didn't work very well, and was part of what led to the development of standardized ABIs in the first place. Those of us who have been around longer than Linux have ABIs have a bit of a strong reaction here (I think this is also what you're seeing from Steve), because we remember the bad old days. I still have compatibility code around to handle the fact that gcc on IRIX miscompiled calls to inet_ntoa because gcc didn't correctly implement the IRIX ABI. People are very bad at judging whether their new idea would be *really* incompatible. This is why these days everyone tries to follow the ABI pretty closely. And in any case, changing PT_INTERP is trivially and obviously incompatible; the binary will simply not run on a system that doesn't have that path. So it's not like we have to carefully judge nuance here. Your argument, so far as I can tell, is basically "but no one will ever want to run those binaries on a non-/usr-merged system anyway," which is basically conceding the incompatibility point since the ABI doesn't require merged /usr. There's also some other history here: Debian is not super-happy with the PT_INTERP because ideally we'd prefer it use a path compatible with our multiarch approach. I believe we raised that and no one had any interest in trying to change anything, so we lived with the limitations that creates. (And I think that was the right decision.) > Thanks, that's the first actual real example mentioned so far. And it's > an interesting one: taking a $random Debian package and using it on a > completely different, non-Debian system. Is that a supported use case? > If so, does that mean that I can go ahead and raise a Severity: serious > bug on any package that doesn't work in such a way? I feel like you're distorting my argument here to try to make some sort of slippery slope argument, and it's coming across as possibly more aggressive than you had intended. The world does not divide neatly into supported and unsupported use cases. There are a lot of things I do to computers that I expect to work in some situations but not in others. That includes, say, having a Debian chroot on some other OS and running binaries from that chroot without going into the chroot. Often that will absolutely not work. Sometimes it will work, and it's convenient that it will work for some obscure recovery situations or other weird one-off use cases. I've also copied files from working systems to broken systems running a different distribution before, and there's a list of caveats as long as my arm, but sometimes it's a quick fix for something. But mostly my reaction is because breaking the ABI is a Really Big Deal. Constructing the Linux ABI and getting the details actually published was a hard-fought, arduous endeavor. I doubt anyone enjoyed it; it's the sort of annoying compatibility work that provides tons of small, subtle benefits and takes a great deal of truly thankless work, and people often don't realize all the tiny ways that it has made the world a better place, or the range of weird compatibility problems that can arise from messing with it. Diverging from it is not something to do lightly, precisely *because* it's often extremely difficult to understand what the effects could be or what might break. While I appreciate how it would make bootstrapping Debian somewhat more convenient in this case, I am unconvinced that this is a good enough reason to undermine one of the foundations of what makes Linux a collective and fairly mutually compatible ecosystem. I realize it's not necessarily obvious that changing PT_INTERP for some binaries is a big deal, in part because it's not even obvious that it's part of the ABI. That's why people who are familiar with the ABI process are jumping in to say "please don't touch that, this is a big deal to us." -- Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2023-05-15 04:40 +0200 |
| Subject | Bug#1035904: dpkg currently warning about merged-usr systems (revisited) |
| Message-ID | <Gvw8h-8Ywq-5@gated-at.bofh.it> |
| In reply to | #107867 |
On Mon, 15 May 2023 at 02:26, Russ Allbery <rra@debian.org> wrote: > > Luca Boccassi <bluca@debian.org> writes: > > > That's self-evidently not true, as there are other distributions where > > that already happens, it's been already mentioned. > > You've mentioned this a couple of times but I don't think I've seen the > message where the details were explained. Maybe this was only in your > message posted to debian-gcc, which wasn't part of this thread? (It's > also possible that I just missed it somewhere.) > > That message only mentions GUIX, which I don't know very much about, but > my recollection (maybe wrong?) is that it's a NIX variant that is doing > special tricks to support immutable package trees and > roll-forward/roll-back upgrades. I can see why that might be motivation > to build incompatible binaries in order to preserve some other invariant > they're trying for as the point of their distribution (in particular, I > suspect they're pinning binaries to a specific version of the dynamic > loader as part of the whole immutable tree strategy). That's a perfectly > fine decision in a distribution that's trying to do something very > different and is a bit of a science experiment, but I don't think that > describes Debian. > > (Also, no slight on the GUIX folks, but GUIX is not exactly an, uh, major > player in Linux distributions, and I'm not sure how much they care about > compatibility with anyone else.) This is a counter-example to confute the assertion that *everybody* does the same thing, which has been made multiple times. I'm not sure whether it's an experiment or not, I mean if you ask their users/developers I think they'd tell you it's very much production ready, but it is largely irrelevant: it exists, and that's the only reason why it was mentioned, as it shows that it is _possible_ to do that and be a working distribution. Doesn't imply it's automatically desirable, but that was not the intention. > > Besides, we are not talking about sacred religious texts - the point is > > making things work. If they do, is it _really_ > > non-compliant/incompatible? > > I understand your point in making this argument, but please understand > that this sort of willingness to change things if one didn't think they > would cause problems didn't work very well, and was part of what led to > the development of standardized ABIs in the first place. Those of us who > have been around longer than Linux have ABIs have a bit of a strong > reaction here (I think this is also what you're seeing from Steve), > because we remember the bad old days. I still have compatibility code > around to handle the fact that gcc on IRIX miscompiled calls to inet_ntoa > because gcc didn't correctly implement the IRIX ABI. > > People are very bad at judging whether their new idea would be *really* > incompatible. This is why these days everyone tries to follow the ABI > pretty closely. > > And in any case, changing PT_INTERP is trivially and obviously > incompatible; the binary will simply not run on a system that doesn't have > that path. So it's not like we have to carefully judge nuance here. Your > argument, so far as I can tell, is basically "but no one will ever want to > run those binaries on a non-/usr-merged system anyway," which is basically > conceding the incompatibility point since the ABI doesn't require merged > /usr. Not quite: my argument is that binaries from these packages are not intended and not required to be ran on non-Debian systems, so there's no incompatibility introduced in the first place - everything still works where it is supposed to, exactly as it was before. > There's also some other history here: Debian is not super-happy with the > PT_INTERP because ideally we'd prefer it use a path compatible with our > multiarch approach. I believe we raised that and no one had any interest > in trying to change anything, so we lived with the limitations that > creates. (And I think that was the right decision.) > > > Thanks, that's the first actual real example mentioned so far. And it's > > an interesting one: taking a $random Debian package and using it on a > > completely different, non-Debian system. Is that a supported use case? > > If so, does that mean that I can go ahead and raise a Severity: serious > > bug on any package that doesn't work in such a way? > > I feel like you're distorting my argument here to try to make some sort of > slippery slope argument, and it's coming across as possibly more > aggressive than you had intended. No aggression intended whatsoever, sorry if it appeared that way. I am trying to understand what the rules are. > The world does not divide neatly into supported and unsupported use cases. > There are a lot of things I do to computers that I expect to work in some > situations but not in others. That includes, say, having a Debian chroot > on some other OS and running binaries from that chroot without going into > the chroot. Often that will absolutely not work. Sometimes it will work, > and it's convenient that it will work for some obscure recovery situations > or other weird one-off use cases. I've also copied files from working > systems to broken systems running a different distribution before, and > there's a list of caveats as long as my arm, but sometimes it's a quick > fix for something. Vast, vast majority of binaries from existing packages will already not work out of the box in that use case though. Why are the existing incompatibilities allowed, and this isn't? > But mostly my reaction is because breaking the ABI is a Really Big Deal. > Constructing the Linux ABI and getting the details actually published was > a hard-fought, arduous endeavor. I doubt anyone enjoyed it; it's the sort > of annoying compatibility work that provides tons of small, subtle > benefits and takes a great deal of truly thankless work, and people often > don't realize all the tiny ways that it has made the world a better place, > or the range of weird compatibility problems that can arise from messing > with it. Diverging from it is not something to do lightly, precisely > *because* it's often extremely difficult to understand what the effects > could be or what might break. I am afraid I am a bit more "pragmatic" than that. I am very interested in what works and what doesn't. Whether it conforms to the letter of the Sacred Ancient Texts... interesting for sure, but secondary. > While I appreciate how it would make bootstrapping Debian somewhat more > convenient in this case, I am unconvinced that this is a good enough > reason to undermine one of the foundations of what makes Linux a > collective and fairly mutually compatible ecosystem. > > I realize it's not necessarily obvious that changing PT_INTERP for some > binaries is a big deal, in part because it's not even obvious that it's > part of the ABI. That's why people who are familiar with the ABI process > are jumping in to say "please don't touch that, this is a big deal to us." Let me ask a simple policy question: why do I have to abide to your uncodified, unwritten use case of running a Debian program from a Debian package from outside a Debian chroot on a foreign, unmodified non-Debian system, but you don't have to abide by my uncodified, unwritten use case of running a Debian program on a Debian system with only a Debian /usr? And also, why it is only this change that has to abide to such use case, and the myriad of cases that cannot possibly work in such a setup are given a free pass (I mean I'm pretty sure the only executables that are guaranteed to work as you mention are golang and rustlang, where everything is statically compiled, everything else is already rc-buggy by that standard)? Isn't this the very reason we have a Policy for, so that we don't get to cherry-pick arbitrary use cases to block things we don't like? Are you really sure we want to be in a place where anybody can bring up an out-of-policy use case as a valid reason to block something they don't like? Again, I am fine if we want to say that Debian-specific changes and Debianisms are bad and we cannot do anything that jeopardises interoperability, cross-distribution harmony and mutual compatibility. But let's do that then, and start by writing it down in Policy so that it applies fairly and equally to all cases. Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2023-05-15 17:30 +0200 |
| Subject | Bug#1035904: dpkg currently warning about merged-usr systems (revisited) |
| Message-ID | <GvI9r-96cX-9@gated-at.bofh.it> |
| In reply to | #107868 |
Luca Boccassi <bluca@debian.org> writes: > On Mon, 15 May 2023 at 02:26, Russ Allbery <rra@debian.org> wrote: >> (Also, no slight on the GUIX folks, but GUIX is not exactly an, uh, >> major player in Linux distributions, and I'm not sure how much they >> care about compatibility with anyone else.) > This is a counter-example to confute the assertion that *everybody* does > the same thing, which has been made multiple times. I'm not sure whether > it's an experiment or not, I mean if you ask their users/developers I > think they'd tell you it's very much production ready, but it is largely > irrelevant: it exists, and that's the only reason why it was mentioned, > as it shows that it is _possible_ to do that and be a working > distribution. Doesn't imply it's automatically desirable, but that was > not the intention. Ah, okay, I'm happy to agree with that point: you can violate the ABI and continue to be a working distribution. (There are a lot of parts of the ABI that if you violated them you would not have a working distribution, but this is not one of them so far as I can tell.) > Not quite: my argument is that binaries from these packages are not > intended and not required to be ran on non-Debian systems, so there's no > incompatibility introduced in the first place - everything still works > where it is supposed to, exactly as it was before. I think we're saying the same thing but quibbling over phrasing. I'd put that as saying that it's fine for the binaries of certain core Debian packages to be incompatible with the ABI because they're not intended to be used outside of Debian. (In other words, I'm talking about incompatibility as a concrete, testable property of a binary, and I think you're talking about incompatibility as a more abstract concept of a distribution.) > No aggression intended whatsoever, sorry if it appeared that way. I am > trying to understand what the rules are. Well, the rule that I'd ideally set is don't break the ABI, even if it's not obvious why breaking the ABI is a bad idea or you can't see any bad consequences that could come from it, unless the reason for breaking the ABI is absolutely central to the mission and purpose of Debian. That said, it's not like we've never shipped a binary in Debian with a different PT_INTERP. (I vaguely remember that some programming language uses PT_INTERP tricks for some sort of private binary scheme? Objective CAML or something? I ran across it once years ago and can't remember the details. Also, IIRC klibc does some sort of PT_INTERP trick in some situations that I don't remember the details of, although I don't think it does that with general binaries.) So I do see your point that you would prefer the rule to be more pragmatic than that. My counterargument is that this proposal seems to mostly be about avoiding having to create a symlink at a critical point in the bootstrap process, and while it's tricky to get the timing right (and therefore kind of annoying), the resulting usable system has to have that symlink anyway (I think there's no disagreement about that). Not following the ABI for core binaries seems like a scary change with unknown consquences to a bunch of core packages to solve what looks like a relatively minor (if admittedly annoying!) problem. Note that the target of PT_INTERP on Debian is *already* a symlink, to /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 which was the multiarch path that we actually want to use. We're already ensuring compatibility with a symlink and I think we should just keep doing that and not venture into these waters. >> The world does not divide neatly into supported and unsupported use >> cases. There are a lot of things I do to computers that I expect to >> work in some situations but not in others. That includes, say, having >> a Debian chroot on some other OS and running binaries from that chroot >> without going into the chroot. Often that will absolutely not work. >> Sometimes it will work, and it's convenient that it will work for some >> obscure recovery situations or other weird one-off use cases. I've >> also copied files from working systems to broken systems running a >> different distribution before, and there's a list of caveats as long as >> my arm, but sometimes it's a quick fix for something. > Vast, vast majority of binaries from existing packages will already > not work out of the box in that use case though. I'm not sure why you think this is true and it makes me wonder if maybe my intuition about cross-distribution compatibility is wrong. I would expect to be able to copy, say, most (all?) binaries from coreutils from a Debian system to some other distribution and run it (and that's exactly the sort of binary that is useful in this kind of cross-distribution rescue case). Is this not true today? What breaks? Note that we're not talking about complicated packages with lots of runtime like, say, Emacs. As I understand it your proposal wouldn't change PT_INTERP for that binary anyway. We're presumably talking about the kind of binaries that you need to bootstrap a minimal system, so packages like coreutils or bash. And I would indeed expect those binaries to be generally portable, as long as the same critical shared libraries are available on other systems (in this case, PCRE2 and ncurses). > Why are the existing incompatibilities allowed, and this isn't? Because it breaks the ABI. I know you don't find that answer satisfying, but that really is my answer. > I am afraid I am a bit more "pragmatic" than that. I am very interested > in what works and what doesn't. Whether it conforms to the letter of the > Sacred Ancient Texts... interesting for sure, but secondary. Right, this is our point of fundamental disagreement. > Let me ask a simple policy question: why do I have to abide to your > uncodified, unwritten use case of running a Debian program from a Debian > package from outside a Debian chroot on a foreign, unmodified non-Debian > system, but you don't have to abide by my uncodified, unwritten use case > of running a Debian program on a Debian system with only a Debian /usr? Well, the concrete answer here is that in order to make this change, you're going to have to convince a bunch of Debian core package maintainers to go along with this change and build their binaries in ways that break the ABI. I believe at least some of them are going to have the same reaction that Steve and I had, and will require a lot of convincing. > And also, why it is only this change that has to abide to such use case, > and the myriad of cases that cannot possibly work in such a setup are > given a free pass (I mean I'm pretty sure the only executables that are > guaranteed to work as you mention are golang and rustlang, where > everything is statically compiled, everything else is already rc-buggy > by that standard)? I really would be surprised if coreutils didn't work, but maybe I'm wrong? It does appear to generally have a PCRE2 requirement, but I would expect a compatible PCRE2 in other distributions of a similar vintage. > Isn't this the very reason we have a Policy for, so that we don't get to > cherry-pick arbitrary use cases to block things we don't like? Policy indeed probably doesn't say that you have to follow the Linux ABI for normal binaries that aren't doing weird language-ecosystem-specific things, but that's partly because it's so foundational and so automatic in normal uses of compilers and linkers that I don't think we ever had any reason to put it into Policy. It certainly didn't occur to me that anyone would want to change the ABI for a subset of Debian packages. Also, I thought you didn't care about Sacred Ancient Texts like Policy. :) > Are you really sure we want to be in a place where anybody can bring up > an out-of-policy use case as a valid reason to block something they > don't like? Yes, I absolutely want to be in a place where anyone can raise any reason that matters to them in public discussion as a reason not to do something they think would be harmful! This is the whole point of working collaboratively together on a shared endeavor. Everyone gets a say! That doesn't mean they get a *veto*, but they get a *say*, and that say is weighted by how much perceived expertise they have and how directly the plan affects their work in Debian. I personally am certainly not expecting to have a veto or even that strong of a say here. This doesn't affect any of my packages so far as I can tell, and I'm far from an expert on the ABI. I've just been around for long enough to pick up something by osmosis. I mostly jumped in because it felt like you and Steve were just yelling at each other and I thought I might be able to explain some of where he was coming from in a way that may make more sense. > Again, I am fine if we want to say that Debian-specific changes and > Debianisms are bad and we cannot do anything that jeopardises > interoperability, cross-distribution harmony and mutual compatibility. > But let's do that then, and start by writing it down in Policy so that > it applies fairly and equally to all cases. I would love to get into a situation where Policy is a comprehensive guide to everything people would like to have rules about in Debian, but I am also pretty sure that if I quit my day job and made Policy my full-time job, that would still not be done in ten years. Distributions are complicated with a lot of moving parts and a lot of those aren't written down. This is why we have people with substantial personal expertise around who can think through novel situations and try to figure out what the possible options and consequences are. It's a good thing! My starting point is that "follow the ABI" is like a safety interlock. Whenever you park a car on a hill, you set the parking brake. You don't try to figure out whether this hill is steep enough to make the car roll, or do complex geometry calculations to try to figure out where the car might roll too; you just set the parking brake always. That makes it a habit, which has its own valuable properties. It means that you set the parking brake in a bunch of places where it's unnecessary to do so in some objective sense, but who cares, it's a habit, it's automatic. You're saying "we don't need to set the parking brake here." You might be right! I'm thinking through the negative consequences of that, but I'm not saying that the specific examples that have come to mind so far are all that compelling. My primary argument is that the logic of always setting the parking brake and not thinking about it is what's compelling, and you're asking us to give up a point of consistency that acts like a safety interlock, and I'm saying that makes me very uncomfortable because it requires we go through this complex process of figuring out what's might go wrong and we also create an inconsistency at a core level of the distribution that may have unforseen consequences. It's a lot easier mentally and conceptually to just always set the parking brake, and complexity is the enemy of any large software project. -- Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2023-05-16 03:50 +0200 |
| Subject | Bug#1035904: dpkg currently warning about merged-usr systems (revisited) |
| Message-ID | <GvRZ7-9c12-1@gated-at.bofh.it> |
| In reply to | #107873 |
On Mon, 15 May 2023 at 16:18, Russ Allbery <rra@debian.org> wrote: > > Luca Boccassi <bluca@debian.org> writes: > > On Mon, 15 May 2023 at 02:26, Russ Allbery <rra@debian.org> wrote: > > >> (Also, no slight on the GUIX folks, but GUIX is not exactly an, uh, > >> major player in Linux distributions, and I'm not sure how much they > >> care about compatibility with anyone else.) > > > This is a counter-example to confute the assertion that *everybody* does > > the same thing, which has been made multiple times. I'm not sure whether > > it's an experiment or not, I mean if you ask their users/developers I > > think they'd tell you it's very much production ready, but it is largely > > irrelevant: it exists, and that's the only reason why it was mentioned, > > as it shows that it is _possible_ to do that and be a working > > distribution. Doesn't imply it's automatically desirable, but that was > > not the intention. > > Ah, okay, I'm happy to agree with that point: you can violate the ABI and > continue to be a working distribution. (There are a lot of parts of the > ABI that if you violated them you would not have a working distribution, > but this is not one of them so far as I can tell.) > > > Not quite: my argument is that binaries from these packages are not > > intended and not required to be ran on non-Debian systems, so there's no > > incompatibility introduced in the first place - everything still works > > where it is supposed to, exactly as it was before. > > I think we're saying the same thing but quibbling over phrasing. I'd put > that as saying that it's fine for the binaries of certain core Debian > packages to be incompatible with the ABI because they're not intended to > be used outside of Debian. (In other words, I'm talking about > incompatibility as a concrete, testable property of a binary, and I think > you're talking about incompatibility as a more abstract concept of a > distribution.) > > > No aggression intended whatsoever, sorry if it appeared that way. I am > > trying to understand what the rules are. > > Well, the rule that I'd ideally set is don't break the ABI, even if it's > not obvious why breaking the ABI is a bad idea or you can't see any bad > consequences that could come from it, unless the reason for breaking the > ABI is absolutely central to the mission and purpose of Debian. > > That said, it's not like we've never shipped a binary in Debian with a > different PT_INTERP. (I vaguely remember that some programming language > uses PT_INTERP tricks for some sort of private binary scheme? Objective > CAML or something? I ran across it once years ago and can't remember the > details. Also, IIRC klibc does some sort of PT_INTERP trick in some > situations that I don't remember the details of, although I don't think it > does that with general binaries.) So I do see your point that you would > prefer the rule to be more pragmatic than that. > > My counterargument is that this proposal seems to mostly be about avoiding > having to create a symlink at a critical point in the bootstrap process, > and while it's tricky to get the timing right (and therefore kind of > annoying), the resulting usable system has to have that symlink anyway (I > think there's no disagreement about that). Not following the ABI for core > binaries seems like a scary change with unknown consquences to a bunch of > core packages to solve what looks like a relatively minor (if admittedly > annoying!) problem. > > Note that the target of PT_INTERP on Debian is *already* a symlink, to > /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 which was the multiarch path > that we actually want to use. We're already ensuring compatibility with a > symlink and I think we should just keep doing that and not venture into > these waters. It's not even a proposal, it's a discussion to see "what would actually break if X happened". That's why I'm asking for concrete use cases, rather than theoretical points. Also, I am interested in what the rules are. For example, glibc compatibility is just as important if not more, why does that follow a different standard? If anything, adding a missing symlink is trivial and a single command. Adding a missing symbol to a shared object... not quite. There is an endless list of downstream-only debianisms that break cross-compatibility in just the same way (if not worse), and yet nobody cares about those. Why? > >> The world does not divide neatly into supported and unsupported use > >> cases. There are a lot of things I do to computers that I expect to > >> work in some situations but not in others. That includes, say, having > >> a Debian chroot on some other OS and running binaries from that chroot > >> without going into the chroot. Often that will absolutely not work. > >> Sometimes it will work, and it's convenient that it will work for some > >> obscure recovery situations or other weird one-off use cases. I've > >> also copied files from working systems to broken systems running a > >> different distribution before, and there's a list of caveats as long as > >> my arm, but sometimes it's a quick fix for something. > > > Vast, vast majority of binaries from existing packages will already > > not work out of the box in that use case though. > > I'm not sure why you think this is true and it makes me wonder if maybe my > intuition about cross-distribution compatibility is wrong. I would expect > to be able to copy, say, most (all?) binaries from coreutils from a Debian > system to some other distribution and run it (and that's exactly the sort > of binary that is useful in this kind of cross-distribution rescue case). > Is this not true today? What breaks? > > Note that we're not talking about complicated packages with lots of > runtime like, say, Emacs. As I understand it your proposal wouldn't > change PT_INTERP for that binary anyway. We're presumably talking about > the kind of binaries that you need to bootstrap a minimal system, so > packages like coreutils or bash. And I would indeed expect those binaries > to be generally portable, as long as the same critical shared libraries > are available on other systems (in this case, PCRE2 and ncurses). Is that really the case? Let's test that hypothesis: root@focal:/tmp# grep VERSION /etc/os-release VERSION="20.04 LTS (Focal Fossa)" VERSION_ID="20.04" VERSION_CODENAME=focal root@focal:/tmp# wget http://ftp.uk.debian.org/debian/pool/main/c/coreutils/coreutils_9.1-1_amd64.deb --2023-05-16 02:07:48-- http://ftp.uk.debian.org/debian/pool/main/c/coreutils/coreutils_9.1-1_amd64.deb Resolving ftp.uk.debian.org (ftp.uk.debian.org)... 2001:1b40:5600:ff80:f8ee::1, 78.129.164.123 Connecting to ftp.uk.debian.org (ftp.uk.debian.org)|2001:1b40:5600:ff80:f8ee::1|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 2896560 (2.8M) [application/octet-stream] Saving to: 'coreutils_9.1-1_amd64.deb' coreutils_9.1-1_amd64.deb 100%[===============================================>] 2.76M 9.66MB/s in 0.3s 2023-05-16 02:07:48 (9.66 MB/s) - 'coreutils_9.1-1_amd64.deb' saved [2896560/2896560] root@focal:/tmp# dpkg -x coreutils_9.1-1_amd64.deb cu root@focal:/tmp# ./cu/usr/bin/stat --help ./cu/usr/bin/stat: /lib/x86_64-linux-gnu/libselinux.so.1: no version information available (required by ./cu/usr/bin/stat) ./cu/usr/bin/stat: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./cu/usr/bin/stat) ./cu/usr/bin/stat: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./cu/usr/bin/stat) Whoops. Does this make coreutils rc-buggy now? ;-) > > Why are the existing incompatibilities allowed, and this isn't? > > Because it breaks the ABI. I know you don't find that answer satisfying, > but that really is my answer. Its purpose is compatibility. If there's no compatibility in the first place, what's its purpose? Or to put it in another way, wouldn't it be more useful to talk about compatibility requirements instead? > > I am afraid I am a bit more "pragmatic" than that. I am very interested > > in what works and what doesn't. Whether it conforms to the letter of the > > Sacred Ancient Texts... interesting for sure, but secondary. > > Right, this is our point of fundamental disagreement. > > > Let me ask a simple policy question: why do I have to abide to your > > uncodified, unwritten use case of running a Debian program from a Debian > > package from outside a Debian chroot on a foreign, unmodified non-Debian > > system, but you don't have to abide by my uncodified, unwritten use case > > of running a Debian program on a Debian system with only a Debian /usr? > > Well, the concrete answer here is that in order to make this change, > you're going to have to convince a bunch of Debian core package > maintainers to go along with this change and build their binaries in ways > that break the ABI. I believe at least some of them are going to have the > same reaction that Steve and I had, and will require a lot of convincing. > > > And also, why it is only this change that has to abide to such use case, > > and the myriad of cases that cannot possibly work in such a setup are > > given a free pass (I mean I'm pretty sure the only executables that are > > guaranteed to work as you mention are golang and rustlang, where > > everything is statically compiled, everything else is already rc-buggy > > by that standard)? > > I really would be surprised if coreutils didn't work, but maybe I'm wrong? > It does appear to generally have a PCRE2 requirement, but I would expect a > compatible PCRE2 in other distributions of a similar vintage. > > > Isn't this the very reason we have a Policy for, so that we don't get to > > cherry-pick arbitrary use cases to block things we don't like? > > Policy indeed probably doesn't say that you have to follow the Linux ABI > for normal binaries that aren't doing weird language-ecosystem-specific > things, but that's partly because it's so foundational and so automatic in > normal uses of compilers and linkers that I don't think we ever had any > reason to put it into Policy. It certainly didn't occur to me that anyone > would want to change the ABI for a subset of Debian packages. And it probably should _not_ say anything about it. However, if cross-distribution compatibility is a core requirement, if not for the whole archive for a subset of it, shouldn't that be defined and written down in the policy? > Also, I thought you didn't care about Sacred Ancient Texts like Policy. :) Policy continuously changes, so it's not really Sacred, is it now :-) > > Are you really sure we want to be in a place where anybody can bring up > > an out-of-policy use case as a valid reason to block something they > > don't like? > > Yes, I absolutely want to be in a place where anyone can raise any reason > that matters to them in public discussion as a reason not to do something > they think would be harmful! This is the whole point of working > collaboratively together on a shared endeavor. Everyone gets a say! That > doesn't mean they get a *veto*, but they get a *say*, and that say is > weighted by how much perceived expertise they have and how directly the > plan affects their work in Debian. It did look like a veto to me. More importantly, isn't relying on passersby to spot alleged harmful changes dangerous, especially for undocumented, uncodified and untested use cases, like unspecified and vague cross-compatibility requirements? > I personally am certainly not expecting to have a veto or even that strong > of a say here. This doesn't affect any of my packages so far as I can > tell, and I'm far from an expert on the ABI. I've just been around for > long enough to pick up something by osmosis. I mostly jumped in because > it felt like you and Steve were just yelling at each other and I thought I > might be able to explain some of where he was coming from in a way that > may make more sense. I don't believe I've done any yelling here. > > Again, I am fine if we want to say that Debian-specific changes and > > Debianisms are bad and we cannot do anything that jeopardises > > interoperability, cross-distribution harmony and mutual compatibility. > > But let's do that then, and start by writing it down in Policy so that > > it applies fairly and equally to all cases. > > I would love to get into a situation where Policy is a comprehensive guide > to everything people would like to have rules about in Debian, but I am > also pretty sure that if I quit my day job and made Policy my full-time > job, that would still not be done in ten years. > > Distributions are complicated with a lot of moving parts and a lot of > those aren't written down. This is why we have people with substantial > personal expertise around who can think through novel situations and try > to figure out what the possible options and consequences are. It's a good > thing! > > My starting point is that "follow the ABI" is like a safety interlock. > Whenever you park a car on a hill, you set the parking brake. You don't > try to figure out whether this hill is steep enough to make the car roll, > or do complex geometry calculations to try to figure out where the car > might roll too; you just set the parking brake always. That makes it a > habit, which has its own valuable properties. It means that you set the > parking brake in a bunch of places where it's unnecessary to do so in some > objective sense, but who cares, it's a habit, it's automatic. > > You're saying "we don't need to set the parking brake here." You might be > right! I'm thinking through the negative consequences of that, but I'm > not saying that the specific examples that have come to mind so far are > all that compelling. My primary argument is that the logic of always > setting the parking brake and not thinking about it is what's compelling, > and you're asking us to give up a point of consistency that acts like a > safety interlock, and I'm saying that makes me very uncomfortable because > it requires we go through this complex process of figuring out what's > might go wrong and we also create an inconsistency at a core level of the > distribution that may have unforseen consequences. It's a lot easier > mentally and conceptually to just always set the parking brake, and > complexity is the enemy of any large software project. What if "setting the parking brake" is not enough, as the wheels are already off and rolling downhill, as shown above, because while everybody was looking at the parking brakes lever somebody ran off with the bolts that kept the wheels attached? Why is it worth worrying about compatibility with something that is already not compatible, and it's not expected to be compatible for almost all other aspects? Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2023-05-16 05:30 +0200 |
| Subject | Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) |
| Message-ID | <GvTxT-9d9r-1@gated-at.bofh.it> |
| In reply to | #107880 |
I'm dropping the TC bug from this thread, since I don't think it has anything to do with that discussion at this point. I probably should also change the Subject line, but I'm keeping it to make it easier for the people who want to tune out this thread, since I very much doubt they want to tune back in at this point. Luca Boccassi <bluca@debian.org> writes: > On Mon, 15 May 2023 at 16:18, Russ Allbery <rra@debian.org> wrote: >> Note that we're not talking about complicated packages with lots of >> runtime like, say, Emacs. As I understand it your proposal wouldn't >> change PT_INTERP for that binary anyway. We're presumably talking >> about the kind of binaries that you need to bootstrap a minimal system, >> so packages like coreutils or bash. And I would indeed expect those >> binaries to be generally portable, as long as the same critical shared >> libraries are available on other systems (in this case, PCRE2 and >> ncurses). > Is that really the case? Let's test that hypothesis: I think you may have not read my whole message before replying, and also please assume that I know really basic facts about glibc compatibility and am not referring to that. I said "of a similar vintage" (farther down in my message) because of course we all know that binaries built against newer versions of glibc don't run on systems with older versions of glibc (and likewise for shared libraries in general and thus libselinux), and you tested a Debian unstable package on an Ubuntu system from 2020. This says nothing interesting and has nothing to do with my point. > Whoops. Does this make coreutils rc-buggy now? ;-) You are the only person who is talking about RC bugs. The bar here is not "prove to me that this is RC buggy," the bar is "you have to prove to a bunch of Debian core maintainers that they should break the ABI in their packages" (not to mention the additional small but permanent build complexity). Demanding they prove to you that it's a bad idea is not how this works. The point of standards like an ABI is that a bunch of entirely unrelated people who never talk to each other and never look at each other's software are allowed to rely on them and assume no one else will break them. This is how free software scales; without invariants that everyone can rely on without having to explain how they're relying on them, it is much more difficult to get an ecosystem to work together. We don't just break things because they don't seem important; the space of people who may be relying on this standard is unknowable, which is the entire point. Opening those boxes is really expensive (in time, planning, communication, debugging, and yes, compatibility) and we should only do it when it really, really matters. > It did look like a veto to me. More importantly, isn't relying on > passersby to spot alleged harmful changes dangerous, especially for > undocumented, uncodified and untested use cases, like unspecified and > vague cross-compatibility requirements? I'm honestly boggled. This is a thread on debian-devel, which is literally how we do architecture vetting in this project. I absolutely do not think that we can write down everything of importance in designing a distribution so that we don't have to have conversations with other people in the project who have deep expertise when considering a significant architectural change like changing the PT_INTERP path of core binaries. >> I mostly jumped in because it felt like you and Steve were just yelling >> at each other and I thought I might be able to explain some of where he >> was coming from in a way that may make more sense. > I don't believe I've done any yelling here. I'm using yelling pretty broadly and probably rather inaccurately here. Maybe a better way of putting it is that Steve was yelling and you didn't appear to be listening or understanding why he was yelling and were responding in ways that were guaranteed to make him yell more. You *are* coming across as kind of contemptuous of other people's arguments, but then it's entirely possible that I am as well, so I'm trying to ignore it. > What if "setting the parking brake" is not enough, as the wheels are > already off and rolling downhill, as shown above, because while > everybody was looking at the parking brakes lever somebody ran off with > the bolts that kept the wheels attached? Why is it worth worrying about > compatibility with something that is already not compatible, and it's > not expected to be compatible for almost all other aspects? You can certainly decide to try to make the argument that ABI compatibility between Linux distributions is a lost cause and we should give up and not care about it any more. That is a valid architectural argument. (To be clear, I don't think this is the argument you've been making up to this point, which is about a very limited ABI break in specific packages to achieve a specific purpose.) I don't agree with that argument, which doubtless doesn't come as a surprise, and your justifications for why you don't think it's important are not persuasive to me. Obviously my arguments are also not persuasive to you, and that's fine, but hopefully you at least understand *what* the arguments are. I realize that you really want to have an argument about specific known and enumerable problems, and part of what I'm trying to get across is that you are not going to get that. I am, in fact, actively opposed to making that the only criteria for decision-making in Debian. Things like standards compatibility, complexity hiding, long-term sustainability, long-term maintenance complexity, anticipated edge cases, previous invariants, and subjective risk are, to me, vitally important to a good architectural process, often *more* important than specific enumerated flaws. -- Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
Back to top | Article view | linux.debian.devel
csiph-web