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 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
| From | Helmut Grohne <helmut@subdivi.de> |
|---|---|
| Date | 2023-06-10 10:50 +0200 |
| Subject | Re: booststrapping /usr-merged systems |
| Message-ID | <GF2iB-eV7m-3@gated-at.bofh.it> |
| In reply to | #108171 |
Hi Sven,
On Sat, Jun 10, 2023 at 08:35:44AM +0200, Sven Joachim wrote:
> > Unfortunately, any
> > external package that still ships stuff in /bin breaks this. In effect,
> > any addon repository or old package can break your system.
>
> You lost me. We have converted /bin to a symlink already, have many
> packages that ship files there and yet our systems do not break. Could
> you please elaborate?
I'm sorry. I see how I am mixing up use cases all the time. What is
broken here is smooth upgrades (or package removal). Let me add detail.
dpkg has two kinds of filesystem resources. These are owned objects and
shared objects. A regular file usually is owned by one and only one
package. A directory is often shared between multiple packages. A
regular file can also be shared between multiple (Multi-Arch: same)
instances of the same package. So whenever a package removes a shared
object from a package (due to upgrading or removing the package), dpkg
checks whether this shared object now is unreferenced. If that happens,
it actually deletes it from the filesystem.
So we kinda need to distinguish the actual filesystem view from the dpkg
database view in this discussion. While the filesystem can now (since
bookworm) be assumed to always have the symlinks, dpkg has a (shared)
object there. It doesn't track the type yet (though Guillem is
working[1] on that).
Now we imagine a situation where we managed to get past this transition
somehow and the end state is that no package in trixie ships /bin other
than base-files, which ships it as a symlink. Or maybe we finished the
transition by having no package ship /bin and we modified the bootstrap
protocol to create the symlinks in another way. There is two use cases
that are at risk now:
* You have some old bookworm package around that still ships a file in
/bin. You no longer need this package and remove it. Since this was
the last package (on your system) to contain /bin (in data.tar), dpkg
observes that /bin can go away and deletes your symlink. Boom.
* You have some external repository that contains a package which still
ships something in /bin. At some point the vendor got the message
about moving files and moves them to /usr/bin and this - again - is
when your /bin symlink vanishes during the package upgrade.
So at this time, I think we basically have three ways of dealing with
this:
1. Add a protective diversion for the affected locations (and keep that
until forky at least).
2. Ship the affected symlinks as directories in some essential package
until we are sure that no package ships these directories (even in
external repositories).
3. Modify dpkg in some way to handle this case.
I hope this made things more clear. Also note that this mail is purely
concerned with dpkg package operations and entirely ignores the
bootstrap use case.
My takeaway here is that while I see the protective diversion as the
"obviously superior solution", this clearly is not consensus at this
time. It also means that when rewriting DEP 17, I need to spend quite a
bit of text on rationale. Thank you.
Helmut
[1] https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking
[toc] | [prev] | [next] | [standalone]
| From | Sven Joachim <svenjoac@gmx.de> |
|---|---|
| Date | 2023-06-10 19:30 +0200 |
| Subject | Re: booststrapping /usr-merged systems |
| Message-ID | <GFazv-f03r-1@gated-at.bofh.it> |
| In reply to | #108174 |
On 2023-06-10 10:39 +0200, Helmut Grohne wrote:
> Hi Sven,
>
> On Sat, Jun 10, 2023 at 08:35:44AM +0200, Sven Joachim wrote:
>> > Unfortunately, any
>> > external package that still ships stuff in /bin breaks this. In effect,
>> > any addon repository or old package can break your system.
>>
>> You lost me. We have converted /bin to a symlink already, have many
>> packages that ship files there and yet our systems do not break. Could
>> you please elaborate?
>
> I'm sorry. I see how I am mixing up use cases all the time. What is
> broken here is smooth upgrades (or package removal). Let me add detail.
>
> dpkg has two kinds of filesystem resources. These are owned objects and
> shared objects. A regular file usually is owned by one and only one
> package. A directory is often shared between multiple packages. A
> regular file can also be shared between multiple (Multi-Arch: same)
> instances of the same package. So whenever a package removes a shared
> object from a package (due to upgrading or removing the package), dpkg
> checks whether this shared object now is unreferenced. If that happens,
> it actually deletes it from the filesystem.
>
> So we kinda need to distinguish the actual filesystem view from the dpkg
> database view in this discussion. While the filesystem can now (since
> bookworm) be assumed to always have the symlinks, dpkg has a (shared)
> object there. It doesn't track the type yet (though Guillem is
> working[1] on that).
>
> Now we imagine a situation where we managed to get past this transition
> somehow and the end state is that no package in trixie ships /bin other
> than base-files, which ships it as a symlink.
That is what I would perceive as the goal. In this case, the /bin
symlink is safe from being removed by dpkg since it is owned by a
package. Or am I missing something?
> Or maybe we finished the
> transition by having no package ship /bin and we modified the bootstrap
> protocol to create the symlinks in another way.
I don not think this is possible, for the two reasons you gave below.
> There is two use cases that are at risk now:
>
> * You have some old bookworm package around that still ships a file in
> /bin. You no longer need this package and remove it. Since this was
> the last package (on your system) to contain /bin (in data.tar), dpkg
> observes that /bin can go away and deletes your symlink. Boom.
>
> * You have some external repository that contains a package which still
> ships something in /bin. At some point the vendor got the message
> about moving files and moves them to /usr/bin and this - again - is
> when your /bin symlink vanishes during the package upgrade.
Cheers,
Sven
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2023-06-10 21:00 +0200 |
| Subject | Re: booststrapping /usr-merged systems |
| Message-ID | <GFbYB-f0K2-1@gated-at.bofh.it> |
| In reply to | #108174 |
On Sat, 10 Jun 2023 at 09:40, Helmut Grohne <helmut@subdivi.de> wrote: > My takeaway here is that while I see the protective diversion as the > "obviously superior solution", this clearly is not consensus at this > time. It also means that when rewriting DEP 17, I need to spend quite a > bit of text on rationale. Thank you. I would caution to avoid interpreting clarifying questions being asked as dissent. It's good to ask questions and clarify details about corner cases, but I wouldn't automatically write them down as disagreement. At least that's my reading of recent parts of this thread. Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Timo Röhling <roehling@debian.org> |
|---|---|
| Date | 2023-06-11 23:20 +0200 |
| Subject | Re: booststrapping /usr-merged systems |
| Message-ID | <GFADD-ffUg-3@gated-at.bofh.it> |
| In reply to | #108177 |
[Multipart message — attachments visible in raw view] — view raw
* Luca Boccassi <bluca@debian.org> [2023-06-10 19:54]: >I would caution to avoid interpreting clarifying questions being asked >as dissent. It's good to ask questions and clarify details about >corner cases, but I wouldn't automatically write them down as >disagreement. At least that's my reading of recent parts of this >thread. This is also my understanding. And for the record, I want to emphasize that I am very much in favor of the plan that Helmut came up with, for a number of reasons: [Full disclosure: I had a few in-person discussions with Helmut in Hamburg last month, so I am probably somewhat biased by now.] 1. Helmut has shown experimentally that his transition plan can work. There are always unknown unknowns, of course, but at the very least, we do not have to break any use-cases intentionally. 2. The transition will leave us in a well-defined state post-trixie without the need to add (and continue to maintain) any clutches (or "special cases") for dpkg. 3. Almost all problematic cases can be dealt with by some black magic in a single usrmerge-support package. It is not pretty, but it will get the job done; a bunch of trickery to make dpkg do the Right Thing despite its incomplete knowledge of aliased paths. 4. We will be able detect the few cases where the Right Thing does not happen transparently, and we can even give advance warning to affected package maintainers what they should and should not do. If the maintainers of those packages pre-upload their transitioned packages to experimental for some automated tests and verification, we can avoid any breakage in unstable and testing. Of course, you do not have to take my word for any of this. I am a big fan of Helmut's approach with experimental verification and data-driven discovery. Have a look at his published test scripts and try to poke holes in them. The more people do this, the more confidence we can have that this might actually work after all. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2023-06-27 21:50 +0200 |
| Subject | Re: booststrapping /usr-merged systems |
| Message-ID | <GLmRl-1lQU-17@gated-at.bofh.it> |
| In reply to | #108187 |
On Sun, 11 Jun 2023 at 22:17, Timo Röhling <roehling@debian.org> wrote: > > * Luca Boccassi <bluca@debian.org> [2023-06-10 19:54]: > >I would caution to avoid interpreting clarifying questions being asked > >as dissent. It's good to ask questions and clarify details about > >corner cases, but I wouldn't automatically write them down as > >disagreement. At least that's my reading of recent parts of this > >thread. > > This is also my understanding. And for the record, I want to > emphasize that I am very much in favor of the plan that Helmut came > up with, for a number of reasons: > > [Full disclosure: I had a few in-person discussions with Helmut in > Hamburg last month, so I am probably somewhat biased by now.] > > > 1. Helmut has shown experimentally that his transition plan can > work. There are always unknown unknowns, of course, but at the very > least, we do not have to break any use-cases intentionally. > > 2. The transition will leave us in a well-defined state post-trixie > without the need to add (and continue to maintain) any clutches > (or "special cases") for dpkg. > > 3. Almost all problematic cases can be dealt with by some black > magic in a single usrmerge-support package. It is not pretty, but it > will get the job done; a bunch of trickery to make dpkg do the Right > Thing despite its incomplete knowledge of aliased paths. > > 4. We will be able detect the few cases where the Right Thing does > not happen transparently, and we can even give advance warning to > affected package maintainers what they should and should not do. If > the maintainers of those packages pre-upload their transitioned > packages to experimental for some automated tests and verification, > we can avoid any breakage in unstable and testing. > > > Of course, you do not have to take my word for any of this. I am a > big fan of Helmut's approach with experimental verification and > data-driven discovery. Have a look at his published test scripts and > try to poke holes in them. The more people do this, the more > confidence we can have that this might actually work after all. Hi Helmut, Any update on this topic? I believe you were working on a write-up, how's that going? Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Steve McIntyre <steve@einval.com> |
|---|---|
| Date | 2023-06-09 17:50 +0200 |
| Subject | Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) |
| Message-ID | <GEMxb-eLf4-9@gated-at.bofh.it> |
| In reply to | #108123 |
Raphaël Hertzog wrote:
>
>In the same spirit, I'd like to throw an idea... could we decide that
>base-files is the first package to be configured as part of the bootstrap
>protocol and change base-files maintainer's scripts into statically linked
>executables so that they can work even if we don't have the library loader
>on the ABI-compliant path?
What exactly do you mean here? You know that even a statically linked
executable needs an interpreter defined in the ELF header?
--
Steve McIntyre, Cambridge, UK. steve@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
note stuck to the mini-bar saying "Paul: This fridge and
fittings are the correct way around and do not need altering"
[toc] | [prev] | [next] | [standalone]
| From | Bjørn Mork <bjorn@mork.no> |
|---|---|
| Date | 2023-06-09 20:00 +0200 |
| Subject | Re: booststrapping /usr-merged systems |
| Message-ID | <GEOyZ-eMpd-3@gated-at.bofh.it> |
| In reply to | #108159 |
Steve McIntyre <steve@einval.com> writes: > Raphaël Hertzog wrote: >> >>In the same spirit, I'd like to throw an idea... could we decide that >>base-files is the first package to be configured as part of the bootstrap >>protocol and change base-files maintainer's scripts into statically linked >>executables so that they can work even if we don't have the library loader >>on the ABI-compliant path? > > What exactly do you mean here? You know that even a statically linked > executable needs an interpreter defined in the ELF header? Maybe I'm missing something, but can't you code a different interpreter path insto such a special purpuse script? #!/usr/lib/x86_64-linux-gnu/ld-2.31.so /usr/bin/dash echo foo [ -e /lib ] || /usr/lib/x86_64-linux-gnu/ld-2.31.so /usr/bin/ln -s /usr/lib /lib or whatever? Bjørn
[toc] | [prev] | [next] | [standalone]
| From | Simon Richter <sjr@debian.org> |
|---|---|
| Date | 2023-06-10 04:30 +0200 |
| Subject | Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) |
| Message-ID | <GEWwx-eRsu-1@gated-at.bofh.it> |
| In reply to | #108159 |
[Multipart message — attachments visible in raw view] — view raw
Hi,
On 10.06.23 00:41, Steve McIntyre wrote:
> What exactly do you mean here? You know that even a statically linked
> executable needs an interpreter defined in the ELF header?
/sbin/ldconfig has no PT_INTERP segment.
If you use libdl, you need to be loaded through ld.so, and since PAM
uses libdl to load plugins, accessing databases doesn't work when
statically linked without an interpreter, so a lot of people use an
interpreter even in a static link, but it's not required (and would be
counterproductive, the interpreter chain needs to terminate somewhere).
Simon
[toc] | [prev] | [next] | [standalone]
| From | David Kalnischkies <david@kalnischkies.de> |
|---|---|
| Date | 2023-05-03 15:10 +0200 |
| Message-ID | <Grkp3-6gPt-3@gated-at.bofh.it> |
| In reply to | #107742 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, May 03, 2023 at 10:31:14AM +0200, Raphael Hertzog wrote: > On Tue, 02 May 2023, Helmut Grohne wrote: > > I think there is a caveat (whose severity I am unsure about): In order > > to rely on this (and on DEP 17), we will likely have versioned > > Pre-Depends on dpkg. Can we reasonably rule out the case where and old > > dpkg is running, unpacking a fixed dpkg, configuring the fixed dpkg and > > then unpacking an affected package still running the unfixed dpkg > > process? APT instructs dpkg to --unpack and to --configure in different calls, you can't mix and match those in the same call and apt never does the (combining) --install (not that it would really matter here). Also, dpkg is essential and as such has to work unpacked aka unpacking a fixed dpkg means that this fixed dpkg will (later) configure itself. Now, given dpkg is essential, it also means it gets the essential treatment from APT (by default) which means it will try to unpack it as soon as possible while trying to keep the time it remains unconfigured at a minimum. Give it a try, you usually see essential packages being interacted with first and in their own calls if you look close enough. That isn't an accident, the idea is that some random 'optional' package failing to install in some way should not leave you in a situation where essentials are in a state of limbo. If you increase the complexity of (pre-)requirements through APT will end up being forced to hand multiple packages in one go. Just pull up the last time you upgraded libc6: You will see a bunch of -dev packages and MultiArch siblings being unpacked alongside libc6 and libc-bin. You will only see those two being configured right after through. The dependencies will it is… so we might have to be a bit careful about the dependencies dpkg carries if such a route is taken. That said, there is always the 'stretch' horror story of APT installing all of KDE before touching dpkg because of the install-info transition… Although that was avoided before the release by removing from dpkg the Breaks leading us into this dark alley… (just to be sure: APT wasn't wrong, the dependencies weren't – but the idea to manually upgrade dpkg first to avoid some pitfalls was suggested which turned out to be wrong). Also, I wonder if we run into Pre-Depends loops and similar nasties given that the essential set is somewhat likely to pre-depend on things which use(d) to be in /lib which would in turn Pre-Depend on dpkg. (I haven't tried and memory is sketchy about those finer more complicated matters, but dpkg certainly can produce working orders for loops by inspecting which maintainer scripts exist or not, so upgrades involving those might or might not work. All bets are off which version of dpkg would be dealing with those through) > I don't know APT well enough to answer that question but from my point of > view it's perfectly acceptable to document in the release notes that you > need to upgrade dpkg first. Those never work in practice through. Nobody logs in on their buildd chroots and upgrades them "properly", we all just hope for the best. Even on systems we care more about people are regularity caught red handed by bothering support with questions whose answers are spelled out in detail in the release notes. Case in point: "Changed security archive layout" last time or "Non-free firmware moved to its own component in the archive" this time around… And those are easy to diagnose and fix. 'You "might" have some "random" files not present on disk. So your system might not even boot or spawns interdimensional portals. You better reinstall…' is not the type of thing you wanna here from support. Best regards David Kalnischkies
[toc] | [prev] | [next] | [standalone]
| From | Bastien ROUCARIES <roucaries.bastien@gmail.com> |
|---|---|
| Date | 2023-04-26 16:50 +0200 |
| Message-ID | <GoOCZ-4FXw-3@gated-at.bofh.it> |
| In reply to | #107675 |
Le mar. 25 avr. 2023 à 19:08, Helmut Grohne <helmut@subdivi.de> a écrit : > > Hi Luca, > > On Sat, Apr 22, 2023 at 01:06:18PM +0100, Luca Boccassi wrote: > > On Sat, 22 Apr 2023 at 11:50, Helmut Grohne <helmut@subdivi.de> wrote: > > > On Fri, Apr 21, 2023 at 03:29:33PM +0100, Luca Boccassi wrote: > > > > After Bookworm ships I plan to propose a policy change to the CTTE and > > > > policy maintainers to forbid shipping files in the legacy directories > > > > altogether, followed by a debhelper change to adjust any stragglers > > > > automatically at build time and a mass rebuild, plus MBF for the small > > > > % that does not use dh and a piuparts test to stop migration for > > > > anything that is uploaded and doesn't comply. That should bring the > > > > matter to an end, without needing to modify dpkg. > > > > > > I agree with the goal of removing aliases by moving files to their > > > canonical locations. However, I do not quite see us getting there in the > > > way you see it, but maybe I am missing something. As long as dpkg does > > > not understand the effects of aliasing, we cannot safely move those > > > files and thus the file move moratorium will have to be kept in place. > > > And while moving the files would bring the matter to an end, we cannot > > > do so without either modifying dpkg or rolling back the transition and > > > starting over. I hope that we all agree that rolling back would be too > > > insane to even consider, but I fail to see how you safely move files > > > without dpkg being changed. Can you elaborate on that aspect? > > > > Moving files within _the same_ package is actually fine as far as I > > know. It's moving between location _and_ packages within the same > > upgrade that is problematic. The piuparts test I added is overzealous, > > but it doesn't need to be. > > You got me interested to dig deeper. I looked into that piuparts > check[1]. From what I understand, it does something differently from > what you suggest here. It detects files moved between / and /usr (which > is what is going to happen according to your plan) and it does not > detect files being moved between packages (which would actually be > problematic here). It also does not produce an error (merely a warning), > so it doesn't halt testing migration and in particular, it doesn't > detect the problematic situation at all. That's kinda disappointing. > > You also side stepped the question of how to handle the situation where > we've moved files from / to /usr and then need to move files between > packages in a safe way, though your other response to Simon McVittie > suggests you have an idea there. > > On Sat, 22 Apr 2023 13:03:01 +0100, Luca Boccassi wrote: > > We already have piuparts tests detecting files moving, it should be > > easy enough to extend that to check that the appropriate > > Breaks/Replaces have been added. Correct me if I'm wrong, but I > > believe it's already against policy to do this without > > Breaks/Replaces, so it's not a use case that we need to support, no? > > If someone does that by mistake, the package will not migrate to > > testing. > > Yeah, we agree that you need Breaks+Replaces. The issue here is that due > to dpkg not knowing about the aliasing, Breaks+Replaces is insufficient. > Due to the insufficiency the CTTE enacted the moratorium. > > My impression is that you believe that with bookworm, the moratorium is > being lifted and thus we can start moving files. Unfortunately, the > underlying problem does not go away just because we've released > bookworm. It's a problem that is unique to merged installations and > those are not going to go away in bookworm. > > So yeah, we all want these files moved to their canonical locations and > I kinda like the simplicity of your approach, but thus far my > understanding is that it is plain broken and doesn't work. Well, yeah it > does work in the sense that we break user installations during upgrade > and notice so late in the freeze without any good options to fix. > > On Sat, Apr 22, 2023 at 01:06:18PM +0100, Luca Boccassi wrote: > > > I'd also be interested on how you plan to move important files in > > > essential packages. This is an aspect raised by Simon Richter and where > > > I do not see an obvious answer yet. > > > > Do you have a pointer? Not sure I follow what "important" files means > > here, doesn't ring a bell. > > In <669234b3-555b-4e2a-ccc7-dd5510b6e9c1@debian.org>, Simon Richter > said: > > Dpkg already has defined behaviour for directory vs symlink: the directory > > wins. In principle a future version of dpkg could change that, but > > /lib/ld-linux.so.2 is just too special, we'd never want to have a package that > > actually moves it. > > This and /bin/sh is the kind of files I'd consider important. And then > upon thinking further it became more and more difficult for me to make > sense of the objection. On a merged system, we can just move that file > to its canonical location without having any trouble even with an > unmodified dpkg. So from my pov, the question about important files can > be disregarded. I hope Simon Richter agrees. > > Let us circle back to your "broken" approach. It sure is simple (just > move all the files and be done) and if we could just skip over the > upgrade issues and have all the files moved without having to modify > dpkg, that would actually be a better result than DEP 17. Just how do we > avoid the issue of file loss arising from the aliasing in your scenario? > > There kinda is an obvious solution here. We just need to tell dpkg that > it needs to remove the package containing the file that is being moved > before unpacking the replacing package. This semantic actually exists > and we call it "Conflicts". So instead of using Breaks+Replaces, the > solution is to use Conflicts! Problem solved, right? > > Yeah, I think this solves a number of cases, but there are two areas > where it does not: > * We generally prefer Breaks over Conflicts for a reason. It gives the > dependency resolver more freedom and in taking this freedom away, it > may fail to find solutions to complex upgrades. (Which is why Breaks > got introduced in the first place.) > * We cannot use Conflicts inside the transitively essential set. > > So if we move all those files, in 90% (number made up) of the cases it > will go well (since we don't move between packages) and in 90% (number > made up) of the remaining 10%, we can use Conflicts, but what do we do > about that remaining 1%? > > If we look deeper into the dpkg toolbox, we pause at diversions. What if > the new package were to add a (--no-rename) diversion for files that are > at risk of being accidentally deleted in newpkg.preinst and then remove > that diversion in newpkg.postinst? Any such diversion will cause package > removal of the oldpkg to skip removal of the diverted file (and instead > deleted the non-existent path that we diverted to). Thus we retain the > files we were interested in. > > This way, we can just move the files as you suggested. > * For 90% of the packages, this will just work. > * For 9% of the packages, we'll need to turn Breaks+Replaces into > Conflicts. > * And for 1% of the packages, we'll need to add complex diversions to > maintainer scripts. Do we have a tool to classify the packages ? Bastien
[toc] | [prev] | [next] | [standalone]
| From | Helmut Grohne <helmut@subdivi.de> |
|---|---|
| Date | 2023-04-27 00:50 +0200 |
| Message-ID | <GoW7v-4KvJ-5@gated-at.bofh.it> |
| In reply to | #107675 |
On Tue, Apr 25, 2023 at 09:07:28PM +0200, Helmut Grohne wrote: > In sincerely hope that this fixed-up plan doesn't have any serious > issues. If you find any please tell. Thanks for the praise, but problems I found and I'm pretty sure this is only the tip of the iceberg. So for one thing, let us imagine merged /usr was mandatory in bullseye already and we were now moving all the files to /usr for bookworm. This is what is on the table for trixie, but since there is no trixie yet, we can try to use the current freeze to see what would happen. To that end, let's look at /lib/systemd/system-generators/systemd-bless-boot-generator. This file was part of systemd in bullseye and has been split out to systemd-boot in bookworm. If it were moved to its canonical location, it could be unpacked by dpkg before upgrading systemd and thus the systemd-bless-boot-generator would vanish from the system despite correct Breaks+Replaces. This is a situation where we'd have to use Conflicts instead. There are actually many more such situations such as: * /bin/fusermount: fuse -> fuse3 * /bin/rksh93: ksh -> ksh93u+m * /lib/systemd/system/dbus.socket: dbus -> dbus-system-bus-common * /lib/systemd/system/dhcpcd.service: dhcpcd5 -> dhcpcd * /lib/systemd/system/polkit.service: policykit-1 -> polkitd * /lib/systemd/system/systemd-resolved.service: systemd -> systemd-resolved * /sbin/hwclock: util-linux -> util-linux-extra * ... This really is a common situation and given the number of systemd units affected, we now also see why not allowing them to move to /usr was a smart thing to do. And that's just the ones where correct Breaks+Replaces have been added. We also have a number of situations where Breaks+Replaces are missing. Ok, let's move on. I've proposed diversions as a cure, but in reality diversions are a problem themselves. Consider that cryptsetup-nuke-password diverts /lib/cryptsetup/askpass, which is usually owned by cryptsetup. If cryptsetup were to move that file to /usr, the diversion would not cover it anymore and the actual content of askpass would depend on the unpack order. That's very bad and none of what I proposed earlier is going to fix this. And of course, this is not some special example, it's a pattern: * /lib/udev/rules.d/60-cdrom_id.rules: udev -> amazon-ec2-utils * /sbin/dhclient: isc-dhcp-client -> isc-dhcp-client-ddns * /bin/systemd-sysusers: systemd -> opensysusers * ... So how do we fix diversions? Let's have a look into the dpkg toolbox again. I've got an idea. Diversions. What you say? How do you fix diversions with diversions? Quite obviously, you divert /usr/bin/dpkg-divert! And whenever dpkg-divert is instructed to add a diversion for a non-canonical path, you forward that call to the real dpkg-divert, but also call it with a canonicalized version such that both locations are covered. When initially deploying the diversion of /usr/bin/dpkg-divert, we also need to transform existing diversions. Other than that, things should work after doubling down on diversions. Sorry, I don't have a test case for this yet. I have a bad feeling about this. I think some dpkg maintainer warned us that diversions would break. Let's peek at his list again. He also said update-alternatives would be broken. I admit not having dug into this yet, but my gut feeling already is that update-alternatives will become "funny" as well though I guess we cannot fix update-alternatives by adding alternatives. So we started with moving some files to their canonical location. We learned that Breaks+Replaces are sometimes insufficient and we can fix that with Conflicts. Then we learned that Conflicts cannot always be used and we can work around that using diversions. Now we learned that diversions are also broken and we can work around that as well. The amount of complexity we are piling up here becomes non-trivial. At some point the question becomes: Do we want that complexity inside dpkg (aka DEP 17 or some variant of it) or outside of dpkg (i.e. what we're talking about here). It seems clear at this time, that complexity is unavoidable. Helmut
[toc] | [prev] | [next] | [standalone]
| From | Simon Richter <sjr@debian.org> |
|---|---|
| Date | 2023-04-27 08:00 +0200 |
| Message-ID | <Gp2PE-4OG3-1@gated-at.bofh.it> |
| In reply to | #107692 |
Hi, On Thu, Apr 27, 2023 at 12:34:06AM +0200, Helmut Grohne wrote: > At some point the question becomes: Do we want that complexity inside > dpkg (aka DEP 17 or some variant of it) or outside of dpkg (i.e. what > we're talking about here). It seems clear at this time, that complexity > is unavoidable. My gut feeling is that returning to "dpkg's model is an accurate representation of the file system" will be less complex to manage long-term. For this to work, the model needs to be able to express reality, so I guess we can't avoid updating dpkg. I'm also not convinced that the current filesystem layout will remain as it is, for example I can see a use case for installing kernel modules outside of /usr. It would be great to have a generic mechanism here, and be able to do transitions like these without inventing new tools every time. Also, the more we can do in a descriptive framework, the better we can do static checks. The main reason we can argue about what packages are affected is that we have a database of what files are installed where, and that still accurately reflects reality, so we can apply a transformation onto this data and check for conflicts -- but we cannot see diversions in this database as these are created from imperative code. So my fear is that if we create a workaround here that is implemented as imperative code in pre/postinst, this will be invisible to whoever plans the next transition, so this would create immense technical debt. Simon
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+debian-devel@zugschlus.de> |
|---|---|
| Date | 2023-04-27 11:00 +0200 |
| Message-ID | <Gp5DP-4Qsv-13@gated-at.bofh.it> |
| In reply to | #107695 |
On Thu, 27 Apr 2023 07:58:35 +0200, Simon Richter <sjr@debian.org> wrote: >On Thu, Apr 27, 2023 at 12:34:06AM +0200, Helmut Grohne wrote: >> At some point the question becomes: Do we want that complexity inside >> dpkg (aka DEP 17 or some variant of it) or outside of dpkg (i.e. what >> we're talking about here). It seems clear at this time, that complexity >> is unavoidable. > >My gut feeling is that returning to "dpkg's model is an accurate >representation of the file system" will be less complex to manage >long-term. For this to work, the model needs to be able to express >reality, so I guess we can't avoid updating dpkg. My gut feeling is that we are wasting prescious time of numerous skilled Debian Developers to find ugly workarounds to something that should be done in dpkg, but isnt being done because one dpkg maintainer has decided to not go the way the project has decided to go. This inability to find consensus, to take decisions, accept and follow them is one of the most central problems that Debian has. Greetings Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Helmut Grohne <helmut@subdivi.de> |
|---|---|
| Date | 2023-04-27 13:00 +0200 |
| Message-ID | <Gp7vX-4REs-3@gated-at.bofh.it> |
| In reply to | #107700 |
Hi Marc, On Thu, Apr 27, 2023 at 10:58:46AM +0200, Marc Haber wrote: > My gut feeling is that we are wasting prescious time of numerous > skilled Debian Developers to find ugly workarounds to something that > should be done in dpkg, but isnt being done because one dpkg > maintainer has decided to not go the way the project has decided to > go. I find this mail of yours very disappointing and possibly even failing our Code of Conduct on multiple accounts. The origin of this thread was a proposal to adapt dpkg. Your mail appears to imply that you are in favour of that approach. Yet, you describe this as wasting time. Can you redirect your energy at reviewing DEP 17 and thus building consensus instead? I would also like to remind you of constitution section 2.1.1. Clearly, Guillem does not like the approach Debian has chosen and chooses to not implement the necessary changes. However, nobody else has done so either. The closest thing to a working patch is what Simon Richter did and even he does not consider it ready for inclusion at the time of this writing. As such, I find the implied accusation disrespectful. > This inability to find consensus, to take decisions, accept and follow > them is one of the most central problems that Debian has. This thread precisely is about finding consensus about a way to move forward. We evaluate multiple different approaches to contain the necessary complexity in parallel. I think this is fine. Your contribution to this process is not constructive. Please reconsider your involvement in this debate. Helmut
[toc] | [prev] | [next] | [standalone]
| From | Marco d'Itri <md@Linux.IT> |
|---|---|
| Date | 2023-04-27 15:40 +0200 |
| Message-ID | <Gpa0N-4Tq1-3@gated-at.bofh.it> |
| In reply to | #107703 |
[Multipart message — attachments visible in raw view] — view raw
On Apr 27, Helmut Grohne <helmut@subdivi.de> wrote: > The origin of this thread was a proposal to adapt dpkg. Your mail No, Marc is right. The origin of this thread is trying to find workaround because the dpkg maintainer refused long ago to implement a simpler solution. -- ciao, Marco
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+debian-devel@zugschlus.de> |
|---|---|
| Date | 2023-04-27 18:40 +0200 |
| Message-ID | <GpcOZ-4Vaf-7@gated-at.bofh.it> |
| In reply to | #107703 |
On Thu, 27 Apr 2023 12:53:31 +0200, Helmut Grohne <helmut@subdivi.de> wrote: >failing >our Code of Conduct The thread went CoC and died. End of discussion for me. -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2023-04-28 21:10 +0200 |
| Message-ID | <GpBDH-5aG9-41@gated-at.bofh.it> |
| In reply to | #107703 |
Helmut Grohne <helmut@subdivi.de> writes: > On Thu, Apr 27, 2023 at 10:58:46AM +0200, Marc Haber wrote: >> My gut feeling is that we are wasting prescious time of numerous >> skilled Debian Developers to find ugly workarounds to something that >> should be done in dpkg, but isnt being done because one dpkg maintainer >> has decided to not go the way the project has decided to go. > I find this mail of yours very disappointing and possibly even failing > our Code of Conduct on multiple accounts. I am unhappy to see the Code of Conduct used in this way. Marc's message was not a personal attack. It did not assume bad faith, or indeed make any statements about motives at all. He expressed his opinion about project priorities and put it in the context of his personal judgment of the facts of the situation as he sees them. You may disagree with his summary of facts, or his opinion about or evaluation of the current situation, or even the usefulness of him raising this point due to lack of resources. It is certainly appropriate to raise those disagreements in response, or even to ignore the message if you don't think it's a constructive line of discussion. (In particular, I think Marc assumes that a solution in dpkg would be more straightforward, something that I think is debatable on technical grounds.) But to say that this is possibly a violation of the Code of Conduct is to say that this message doesn't meet the bar for civil discussion on our lists, and I think it is unreasonable to expect anyone to be more civil or even-handed than Marc was in his summary of behavior that he strongly disagrees with. (And, to state the obvious, I don't believe that message was a violation of our Code of Conduct.) Trying to set the bar higher than this would have the effect of forbidding particular types of hard conversations, which is not healthy for the project. We have to be able to talk about interpersonal disagreements and problems of alignment of motives and goals among the people working on the project. Sometimes those discussions are going to be uncomfortable, but we can't ignore them and never discuss them because they're uncomfortable. We are a collection of humans working together collaboratively, which means there will be tension and conflict and we have to deal with that, constructively but honestly and forthrightly. Part of working collaboratively with other people is that those people get to criticize how you are doing your work, as long as they do so respectfully and assuming good faith. Sometimes that includes saying that one believes the actions of another developer are causing a misallocation of project resources or time. Whether or not we end up agreeing that is true, this is a valid topic for discussion, and sometimes it is feedback that other developers need to hear so that they can do some introspection and evaluate whether that may indeed be the case. -- Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
| From | Holger Levsen <holger@layer-acht.org> |
|---|---|
| Date | 2023-04-27 14:00 +0200 |
| Message-ID | <Gp8s1-4Sfl-1@gated-at.bofh.it> |
| In reply to | #107700 |
[Multipart message — attachments visible in raw view] — view raw
On Thu, Apr 27, 2023 at 10:58:46AM +0200, Marc Haber wrote: > My gut feeling is that we are wasting prescious time of numerous > skilled Debian Developers to find ugly workarounds to something that > should be done in dpkg, but isnt being done because one dpkg > maintainer has decided to not go the way the project has decided to > go. fwiw, I largely agree with this. Constitution 2.1.1 is great, however we don't really have a mechanism how to deal with people flat out ignoring Constitution 6 aka the tech-ctte and doubting and activly working against it's decisions. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ It ain't no revolution, just because you can dance to it.
[toc] | [prev] | [next] | [standalone]
| From | Simon Richter <sjr@debian.org> |
|---|---|
| Date | 2023-04-27 17:00 +0200 |
| Message-ID | <Gpbgd-4U9b-11@gated-at.bofh.it> |
| In reply to | #107705 |
Hi, On Thu, Apr 27, 2023 at 11:57:58AM +0000, Holger Levsen wrote: > Constitution 2.1.1 is great, however we don't really have a mechanism how to > deal with people flat out ignoring Constitution 6 aka the tech-ctte and doubting > and activly working against it's decisions. We have: we can find a new maintainer and transfer the package. For that to happen, someone would have to step up and volunteer to either develop the necessary functionality, or accept a patch that does so, and then continue as maintainer. This has not happened. I also doubt it will happen, because anyone capable of maintaining a core system component such as dpkg is aware that nothing implemented so far is of sufficient quality that they want to be responsible for its continued maintenance. The tech-ctte decision mainly adds an additional constraint on proposed solutions: they may not require a temporary rollback (through dpkg-usrunmess or similar), but must accept transitioned and half- transitioned systems as they are, and bring them to a fully-transitioned and consistent state. It's unclear if it also means that dpkg need not provide a way to remove aliases. This adds a moderate amount of additional complexity as we need to add more checks to hot paths in dpkg, and we need to verify that these code paths work. In my opinion, having these paths will add robustness to dpkg, so we want them anyway, so this doesn't add further delay. The core problem remains however: the tech-ctte decision has not made code appear, and the Constitution is also powerless to do so. Simon
[toc] | [prev] | [next] | [standalone]
| From | Helmut Grohne <helmut@subdivi.de> |
|---|---|
| Date | 2023-04-28 10:10 +0200 |
| Message-ID | <GprkZ-54z0-5@gated-at.bofh.it> |
| In reply to | #107692 |
On Thu, Apr 27, 2023 at 12:34:06AM +0200, Helmut Grohne wrote: > Ok, let's move on. I've proposed diversions as a cure, but in reality > diversions are a problem themselves. Consider that > cryptsetup-nuke-password diverts /lib/cryptsetup/askpass, which is > usually owned by cryptsetup. If cryptsetup were to move that file to > /usr, the diversion would not cover it anymore and the actual content of > askpass would depend on the unpack order. That's very bad and none of > what I proposed earlier is going to fix this. > > And of course, this is not some special example, it's a pattern: > * /lib/udev/rules.d/60-cdrom_id.rules: udev -> amazon-ec2-utils > * /sbin/dhclient: isc-dhcp-client -> isc-dhcp-client-ddns > * /bin/systemd-sysusers: systemd -> opensysusers > * ... > > So how do we fix diversions? Let's have a look into the dpkg toolbox > again. I've got an idea. Diversions. What you say? How do you fix > diversions with diversions? Quite obviously, you divert > /usr/bin/dpkg-divert! And whenever dpkg-divert is instructed to add a > diversion for a non-canonical path, you forward that call to the real > dpkg-divert, but also call it with a canonicalized version such that > both locations are covered. When initially deploying the diversion of > /usr/bin/dpkg-divert, we also need to transform existing diversions. > Other than that, things should work after doubling down on diversions. > Sorry, I don't have a test case for this yet. I still don't have a test case, but I have data. Using binarycontrol.d.n, I identified packages setting up diversions in preinst (this seems most common, but dash for instance sets up a diversion in postinst instead, so there are some false negatives). And while I initially tried to parse those preinst scripts, solving the halting problem seemed just too hard, so I opted for just running them. I'm attaching the relevant scripts and showing the affected diversions: diversion of /lib/udev/rules.d/60-cdrom_id.rules to /lib/udev/rules.d/60-cdrom_id.rules.disabled by amazon-ec2-utils in stable, testing, unstable diversion of /sbin/coldreboot to /lib/container/divert/coldreboot.orig by bfh-container in testing, unstable diversion of /sbin/halt to /lib/container/divert/halt.orig by bfh-container in testing, unstable diversion of /sbin/poweroff to /lib/container/divert/poweroff.orig by bfh-container in testing, unstable diversion of /sbin/reboot to /lib/container/divert/reboot.orig by bfh-container in testing, unstable diversion of /sbin/shutdown to /lib/container/divert/shutdown.orig by bfh-container in testing, unstable diversion of /lib/cryptsetup/askpass to /lib/cryptsetup/askpass.cryptsetup by cryptsetup-nuke-password in testing, unstable diversion of /sbin/dhclient to /sbin/dhclient-noddns by isc-dhcp-client-ddns in stable, testing, unstable diversion of /sbin/coldreboot to /lib/molly-guard/coldreboot by molly-guard in stable, testing, unstable diversion of /sbin/halt to /lib/molly-guard/halt by molly-guard in stable, testing, unstable diversion of /sbin/poweroff to /lib/molly-guard/poweroff by molly-guard in stable, testing, unstable diversion of /sbin/reboot to /lib/molly-guard/reboot by molly-guard in stable, testing, unstable diversion of /sbin/shutdown to /lib/molly-guard/shutdown by molly-guard in stable, testing, unstable diversion of /bin/systemd-sysusers to /bin/systemd-sysusers.real by opensysusers in stable, testing, unstable diversion of /sbin/coldreboot to /lib/open-infrastructure/container/divert/coldreboot.orig by progress-linux-container in stable, testing, unstable diversion of /sbin/halt to /lib/open-infrastructure/container/divert/halt.orig by progress-linux-container in stable, testing, unstable diversion of /sbin/poweroff to /lib/open-infrastructure/container/divert/poweroff.orig by progress-linux-container in stable, testing, unstable diversion of /sbin/reboot to /lib/open-infrastructure/container/divert/reboot.orig by progress-linux-container in stable, testing, unstable diversion of /sbin/shutdown to /lib/open-infrastructure/container/divert/shutdown.orig by progress-linux-container in stable, testing, unstable diversion of /bin/zcat to /bin/zcat.gzip by zutils in stable, testing, unstable diversion of /bin/zcmp to /bin/zcmp.gzip by zutils in stable, testing, unstable diversion of /bin/zdiff to /bin/zdiff.gzip by zutils in stable, testing, unstable diversion of /bin/zegrep to /bin/zegrep.gzip by zutils in stable, testing, unstable diversion of /bin/zfgrep to /bin/zfgrep.gzip by zutils in stable, testing, unstable diversion of /bin/zgrep to /bin/zgrep.gzip by zutils in stable, testing, unstable All other diversion affect /etc or /usr and I think we're not going to move any files from /usr to /. So this is a complete list as of today and I have to say, I expected it to be longer. In effect, we're talking about merely 8 packages. For completeness sake, I also looked at the other packages mentioning dpkg-divert in their preinst to catch false negatives. I'll skip diversions inside /usr as well as removals of diversions here: * amazon-ec2-net-utils: diversion inside /etc * angband: comment about diversions * arpwatch: comment about diversions * dash: complex use of conditional diversions via postinst * dist: comment about diversions * gpr: conditional diversion (inside /usr) * iputils-arping: check for an existing diversion * iputils-clockdiff: check for an existing diversion * iputils-ping: check for an existing diversion * ld10k1: comment about diversions * mailagent: comment about diversions * oping: checks for an existing diversion * psgml: comment about diversions * ucf: comment about diversions * wireshark-common: checks for an existing diversion So yeah, with the exception of dash, this looks fairly good. Let me also dive into dash. Unlike the majority of diverters, it diverts in postinst rather than preinst to allow controlling /bin/sh via debconf. A similar technique is in effect by gpr. In any case, this is special, because dash diverts its own files, so when moving dash's file, its diversions can be migrated at the same time. It merely means, that we cannot have debhelper just move files (as that would horribly break dash) and instead have to move files on a package-by-package way. We could also opt for removing dash's diversion in the default case and there even is a patch for doing so (#989632) since almost two years. Too bad we didn't apply it. In any case, as long as the file moving is not forced via debhelper, dash should be harmless. With this number, another option is on the table. Rather than divert dpkg-divert, we could just fix these 8 packages to duplicate their diversions for /usr and then when moving the underlying files add versioned Conflicts to the old version of diverters (none of which are essential). So this is an order of 15 uploads (8 diverters, 6 diverted packages, dash). Luca Boccassi kindly pointed me at config-package-dev though. This is a tool for generating local packages and it also employs dpkg-divert. There is a significant risk of breaking this use case. If we were to divert dpkg-divert and automatically duplicate diversions, this use case were automatically covered. I am unsure how to proceed here and request assistance from the debathena project to evaluate the situation. If possible, I'd like to avoid the complexity of wrapping dpkg-divert. Helmut
[toc] | [prev] | [next] | [standalone]
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
Back to top | Article view | linux.debian.devel
csiph-web