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 1 of 10 [1] 2 3 … 10 Next page →
| From | Helmut Grohne <helmut@subdivi.de> |
|---|---|
| Date | 2023-04-03 14:10 +0200 |
| Subject | DEP 17: Improve support for directory aliasing in dpkg |
| Message-ID | <Ggrax-h450-7@gated-at.bofh.it> |
Hi, I have been looking into the aliasing problems in dpkg on behalf of Freexian's Debian funding. To that end I proposed a possible way forward last year (https://lists.debian.org/debian-dpkg/2022/11/msg00007.html), but the feedback I got was not particularly helpful in determining consensus. A little later, Simon Richter also looked into the problem (https://lists.debian.org/debian-dpkg/2022/12/msg00023.html), but remained silent after the initial post. Little happened since then. Now Raphael Hertzog proposed to use the DEP process to get this thing unstuck and with the help of Emilio Pozuelo Monfort I created a draft for discussion. I allocate number 17 via debian-project@l.d.o. What follows is the draft text. Please consider it to be a piece of best intentions at reconciling feedback wherever I could. At the time of this writing it certainly is not consensus, but consensus is what I seek here. Without further ado, the full DEP text follows after my name while it also is available at https://salsa.debian.org/dep-team/deps/-/merge_requests/5 Helmut Introduction ============ At its core, `dpkg` assumes that every filename uniquely refers to a file on disk. The situation where two distinct filenames refer to the same file on disk is referred to as aliasing. Violating this assumption leads to undefined behaviour such as file loss. The assumption is commonly violated when a leading directory component contains a symbolic link. A situation where this is known to cause file loss happens when a file is moved from one binary package to another binary package while at the same time changing the filename in a way that retains its final location. In this situation, `dpkg` may first unpack the new replacing location and then remove the replaced package thus unknowingly remove the aliased file. Other components such as `dpkg-divert` or `update-alternatives` are likely affected in similar ways. The purpose of this DEP is selecting and implementing a change to `dpkg` to improve the way it handles such situations that affect typical Debian installations. Naive solution ============== In theory, `dpkg` could resolve this automatically. For every file it touches, it could canonicalize the location using the actual filesystem and check whether any other installed file has the same canonicalized location. Unfortunately, `dpkg` cannot know which filenames can collide, so it would check every filename in its database. For canonicalization, it would `stat()` every component of every filename. This easily amounts to a million or more `stat()` calls on larger installations. Caching could reduce the impact somewhat, but since Debian introduces aliases during maintainer scripts, it would have to invalidate the cache after maintainer scripts have been run. The resulting performance would be unacceptable. Proposal ======== In order to handle aliasing efficiently, `dpkg` gains new options `--add-alias <symlink>`, `--remove-alias <symlink>` and `--list-aliases`. When creating symbolic links that cause aliasing effects, the creating entity is supposed to inform `dpkg` using an appropriate invocation. Doing so records the aliasing information in a new mapping inside its administrative directory. No existing administrative files are modified as a result of this operation. When `dpkg` operates on paths, it can compute a canonicalized version using a pure function without the need to `stat()` files on disk thus greatly improving performance. Canonicalized paths are only needed when determining whether a file conflict exists. In all other cases, original paths continue to be used as symbolic links will be followed by filesystem operations. The `--add-alias` operation records the target of the symbolic link that must exist prior to invocation. The `--remove-alias` operation fails if any files are still installed in the aliased location. Rejected proposals ================== Hardcoding aliases into dpkg ---------------------------- It was suggested to include a static aliasing mapping into the `dpkg` source code. Since `dpkg` is used by multiple projects in different ways (not necessarily Debian-derivatives), this approach would break other consumers. Also note that Debian's `dpkg` can be used to operate on an installation using different aliases via the `--root` flag. As such the alias mapping needs to be a property of the installation. Modifying package lists in place -------------------------------- `dpkg` could rewrite the extracted `.list` files from `control.tar` and store paths in canonicalized form. Canonicalization would happen as when a `control.tar` is extracted. It would also happen either as a one-time conversion during the upgrade of `dpkg` or whenever a `.list` file is read. Given canonicalized list files, string comparison on files would support conflict detection. Other pieces to be updated in a similar way include `alternatives`, `diversions`, `statoverride`, and `triggers`. This would affect the output of `dpkg -S`, which would then output canonicalized paths. Packages generated by `dpkg-repack` would have their contents canonicalized as well. Managing the aliasing mapping using a control file -------------------------------------------------- It was suggested that the mapping could be managed via a special control file `canonical`. Given that aliasing is not a common operation, the benefit of handling it declaratively is minor. Beyond that, aliasing can also happen as an customization issued by an administrator. Therefore, a command line based approach is preferred. Having dpkg move files and create symbolic links ------------------------------------------------ When instructed with `--add-alias`, `dpkg` could also create the corresponding symbolic links and move the affected files to their new location. While that would be convenient, doing so is non-trivial in an atomic way. Sometimes, the underlying filesystem does not fully conform to POSIX (e.g. `overlayfs`) and such corner cases need to be managed individually. Since such an implementation already exists outside `dpkg` and its complexity is non-trivial, the moving of files shall remain external. In case aliases are setup in a bootstrap setting, no moves are necessary. Implement aliasing after metadata tracking ------------------------------------------ The [metadata tracking](https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking) feature enhances `dpkg` with knowledge about filesystem metadata for installed files. This includes knowledge of symbolic links, which would help with tracking aliasing. Unfortunately, progress on this is fairly slow and we think that aliasing support is more urgent. Proposal internals ================== A new file `aliases` is added to the administrative directory. Pairs of lines containing link name and destination indicate an alias. Within this file, no link name or destination may contain another link name. The `--add-alias` and `--remove-alias` options change this file only and must ensure that the properties are retained. This leads to a trivial algorithm for canonicalizing paths. A given path can be scanned for recorded link names as sub path and have them replaced with the recorded destination. This process is repeated until a scan passes without performing a substitution. Usually, two scan passes will be sufficient. Much of the internal work has been prototyped by [Simon Richter](https://salsa.debian.org/sjr/dpkg/-/tree/wip-canonical-paths) and can be used. It demonstrates how the `fsys_namenode` can be augmented with a canonicalized path and how `fsys_hash_find_node` can be extended with a new flag to differentiate between lookups considering aliases or exact names. It differs from what is proposed here in the API to configure aliases and in possibly storing partially canonicalized versions of file names.
[toc] | [next] | [standalone]
| From | Raphael Hertzog <hertzog@debian.org> |
|---|---|
| Date | 2023-04-21 14:20 +0200 |
| Message-ID | <GmXU5-3vM9-3@gated-at.bofh.it> |
| In reply to | #107571 |
Hello, On Mon, 03 Apr 2023, Helmut Grohne wrote: > Please consider it to be a piece of best > intentions at reconciling feedback wherever I could. At the time of this > writing it certainly is not consensus, but consensus is what I seek > here. Without further ado, the full DEP text follows after my name > while it also is available at > https://salsa.debian.org/dep-team/deps/-/merge_requests/5 I'd like to express some disappointment that nobody replied publicly sofar. Last year's developer survey concluded that "Debian should complete the merged-/usr transition" was the most important project for Debian [1] (among those proposed in the survey). That's what we are trying to do here and it would be nice to build some sort of consensus on what it means in terms of changes for dpkg. I know that Guillem (dpkg's maintainer) is generally opposed to the approach that Debian has followed to implement merged-/usr but I have yet to read his concerns on the changes proposed here (besides the fact that they ought to not be needed because we should redo the transition in another way, but that's a ship that has sailed a long time ago...). The rough project consensus seems to be that we should modify dpkg to avoid the cases where some files can disappear upon upgrades. Most people don't really care how we modify dpkg for this, and I can't blame them, but given that dpkg's maintainer seems unwilling to work on this problem, someone else has to come up with a design, implement it and get it applied on Debian's version of dpkg. We are committed to work on the design and implementation but we want to make sure the design is sound and agreed upon by the persons who are technically knowledgeable on this issue and who have thought a lot on this issue. There aren't that many persons in that set but it is also not empty. So please read the DEP and share your feedback, even if it's just "I have read it and it sounds fine", it will definitely help. Thank you! [1] page 28-32 of https://debian.pages.debian.net/dd-surveys/dd-survey-analysis-2022.pdf -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org> ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <luca.boccassi@gmail.com> |
|---|---|
| Date | 2023-04-21 16:50 +0200 |
| Message-ID | <Gn0ff-3x3G-5@gated-at.bofh.it> |
| In reply to | #107644 |
On Fri, 21 Apr 2023 at 13:16, Raphael Hertzog <hertzog@debian.org> wrote: > > Hello, > > On Mon, 03 Apr 2023, Helmut Grohne wrote: > > Please consider it to be a piece of best > > intentions at reconciling feedback wherever I could. At the time of this > > writing it certainly is not consensus, but consensus is what I seek > > here. Without further ado, the full DEP text follows after my name > > while it also is available at > > https://salsa.debian.org/dep-team/deps/-/merge_requests/5 > > I'd like to express some disappointment that nobody replied publicly > sofar. Last year's developer survey concluded that "Debian should complete > the merged-/usr transition" was the most important project for Debian [1] > (among those proposed in the survey). That's what we are trying to do > here and it would be nice to build some sort of consensus on what it means > in terms of changes for dpkg. > > I know that Guillem (dpkg's maintainer) is generally opposed to the > approach that Debian has followed to implement merged-/usr but I have > yet to read his concerns on the changes proposed here There was an answer from the maintainer, 2 weeks ago: https://lists.debian.org/debian-dpkg/2023/04/msg00001.html Essentially, the answer was "no", so... 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. Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2023-04-22 12:50 +0200 |
| Message-ID | <GniYx-3IDr-5@gated-at.bofh.it> |
| In reply to | #107646 |
On Fri, 21 Apr 2023 at 15:29:33 +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
That seems quite likely to trigger the scenario Helmut is trying to avoid,
which if I understand correctly is this:
* foo_12.0 in Debian 12 ships /lib/abcd
* bar_13.0 takes over /lib/abcd from foo, but because of either your
proposed change or a manual action by the maintainer, it is actually in
the data.tar as ./usr/lib/abcd (not ./lib/abcd like it was in foo_12.0)
* the maintainer of bar didn't add the correct Breaks/Replaces on foo
* a user upgrading from Debian 12 to 13 installs bar_13.0, perhaps pulled
in as a dependency
* expected result: dpkg refuses to unpack bar ("trying to overwrite ..."),
the upgrade is cancelled, and the user reports a RC bug in bar
* actual result: /usr/lib/abcd in bar quietly overwrites /lib/abcd from foo
* if bar is subsequently removed, then dpkg (and therefore apt) thinks foo
is fully functional, but in fact /{usr/,}lib/abcd is missing
(For simplicity I've described that scenario in terms of files directly
shipped in the data.tar, but dpkg also tracks the ownership of files
created by dpkg-divert or alternatives, and similar things can happen
to those.)
I had hoped that the last section of technical committee resolution
#994388 (which concerns this situation) would become irrelevant in Debian
13, but it's looking as though without the sort of dpkg changes discussed
in this thread, the concern about files moving between packages would
remain a valid concern.
However, as far as I can see, the other reasons not to do this that were
mentioned in the last section of #994388 *do* become irrelevant in Debian
13, so solving the files-moved-between-packages thing is the last major
blocker for doing what you propose. (Unless someone has a reason why this
is not the case?)
You might reasonably say that "the maintainer of bar didn't add the
correct Breaks/Replaces on foo" is a RC bug in bar - and it is! - but
judging by the number of "missing Breaks/Replaces" bug reports that have
to be opened by unstable users (sometimes me), it's a very easy mistake
to make.
One thing that's particularly tricky about this is that the move from
/ into /usr and the move from foo to bar might be 18 months apart if
they happen to occur at opposite ends of our stable release cycle. In
particular, if the move from / into /usr is done as soon as the Debian 13
cycle opens, we cannot predict whether the packages that have undergone
that move will also need to undergo a package split/merge at some point
in the following 18 months (but it's reasonable to assume that at least
some of them will).
smcv
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <luca.boccassi@gmail.com> |
|---|---|
| Date | 2023-04-22 14:30 +0200 |
| Message-ID | <Gnkxj-3JHS-3@gated-at.bofh.it> |
| In reply to | #107651 |
On Sat, 22 Apr 2023 at 11:41, Simon McVittie <smcv@debian.org> wrote:
>
> On Fri, 21 Apr 2023 at 15:29:33 +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
>
> That seems quite likely to trigger the scenario Helmut is trying to avoid,
> which if I understand correctly is this:
>
> * foo_12.0 in Debian 12 ships /lib/abcd
> * bar_13.0 takes over /lib/abcd from foo, but because of either your
> proposed change or a manual action by the maintainer, it is actually in
> the data.tar as ./usr/lib/abcd (not ./lib/abcd like it was in foo_12.0)
> * the maintainer of bar didn't add the correct Breaks/Replaces on foo
> * a user upgrading from Debian 12 to 13 installs bar_13.0, perhaps pulled
> in as a dependency
> * expected result: dpkg refuses to unpack bar ("trying to overwrite ..."),
> the upgrade is cancelled, and the user reports a RC bug in bar
> * actual result: /usr/lib/abcd in bar quietly overwrites /lib/abcd from foo
> * if bar is subsequently removed, then dpkg (and therefore apt) thinks foo
> is fully functional, but in fact /{usr/,}lib/abcd is missing
>
> (For simplicity I've described that scenario in terms of files directly
> shipped in the data.tar, but dpkg also tracks the ownership of files
> created by dpkg-divert or alternatives, and similar things can happen
> to those.)
>
> I had hoped that the last section of technical committee resolution
> #994388 (which concerns this situation) would become irrelevant in Debian
> 13, but it's looking as though without the sort of dpkg changes discussed
> in this thread, the concern about files moving between packages would
> remain a valid concern.
>
> However, as far as I can see, the other reasons not to do this that were
> mentioned in the last section of #994388 *do* become irrelevant in Debian
> 13, so solving the files-moved-between-packages thing is the last major
> blocker for doing what you propose. (Unless someone has a reason why this
> is not the case?)
>
> You might reasonably say that "the maintainer of bar didn't add the
> correct Breaks/Replaces on foo" is a RC bug in bar - and it is! - but
> judging by the number of "missing Breaks/Replaces" bug reports that have
> to be opened by unstable users (sometimes me), it's a very easy mistake
> to make.
>
> One thing that's particularly tricky about this is that the move from
> / into /usr and the move from foo to bar might be 18 months apart if
> they happen to occur at opposite ends of our stable release cycle. In
> particular, if the move from / into /usr is done as soon as the Debian 13
> cycle opens, we cannot predict whether the packages that have undergone
> that move will also need to undergo a package split/merge at some point
> in the following 18 months (but it's reasonable to assume that at least
> some of them will).
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.
Kind regards,
Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Sam Hartman <hartmans@debian.org> |
|---|---|
| Date | 2023-04-26 15:20 +0200 |
| Message-ID | <GoNdT-4FcV-3@gated-at.bofh.it> |
| In reply to | #107651 |
>>>>> "Simon" == Simon McVittie <smcv@debian.org> writes:
Simon> You might reasonably say that "the maintainer of bar didn't
Simon> add the correct Breaks/Replaces on foo" is a RC bug in bar -
Simon> and it is! - but judging by the number of "missing
Simon> Breaks/Replaces" bug reports that have to be opened by
Simon> unstable users (sometimes me), it's a very easy mistake to
Simon> make.
Is adding the correct breaks/replaces enough to solve things?
I could believe adding a versioned conflicts would be sufficient, but it
is not obvious to me that breaks/replaces is enough given that dpkg
doesn't understand aliasing.
My intuition (and I have not worked through this as much as you) is that
any time you can have files moving where both packages are unpacked can
create problems.
I think that can happen with breaks/replaces but not without a conflicts
(without replaces?)
[toc] | [prev] | [next] | [standalone]
| From | Helmut Grohne <helmut@subdivi.de> |
|---|---|
| Date | 2023-04-27 00:50 +0200 |
| Message-ID | <GoW7v-4KvJ-3@gated-at.bofh.it> |
| In reply to | #107685 |
On Wed, Apr 26, 2023 at 07:11:10AM -0600, Sam Hartman wrote:
> >>>>> "Simon" == Simon McVittie <smcv@debian.org> writes:
>
> Simon> You might reasonably say that "the maintainer of bar didn't
> Simon> add the correct Breaks/Replaces on foo" is a RC bug in bar -
> Simon> and it is! - but judging by the number of "missing
> Simon> Breaks/Replaces" bug reports that have to be opened by
> Simon> unstable users (sometimes me), it's a very easy mistake to
> Simon> make.
Indeed, I was thinking that we correctly to Breaks and Replaces. I now
know better and files an initial batch of four rc bugs for missing
cases. So yeah, quite clearly we need to fix this more systematically,
but I think that's technically possible:
1. Download all Contents and Packages files for stable and testing.
2. Generate candidates for file conflicts from the Contents.
3. Skip cases covered by Breaks+Replaces or Conflicts.
3b. Optionally also parse binarycontrol.d.n data to be able to skip
known diversions.
4. Create a fresh stable chroot and install the "old" package.
5. Update sources.list to testing and download the "new" package.
6. dpkg --auto-configure --unpack new.pkg.
7. Check output for "trying to overwrite".
> Is adding the correct breaks/replaces enough to solve things?
> I could believe adding a versioned conflicts would be sufficient, but it
> is not obvious to me that breaks/replaces is enough given that dpkg
> doesn't understand aliasing.
It is not.
> My intuition (and I have not worked through this as much as you) is that
> any time you can have files moving where both packages are unpacked can
> create problems.
This is exactly the situation that caused the moratorium.
> I think that can happen with breaks/replaces but not without a conflicts
> (without replaces?)
Yes, Conflicts can in situations where Breaks+Replaces would fail due to
the aliasing issue. My mail from yesterday goes into more detail and
also explains when you cannot use Conflicts.
Helmut
[toc] | [prev] | [next] | [standalone]
| From | Helmut Grohne <helmut@subdivi.de> |
|---|---|
| Date | 2023-04-27 15:40 +0200 |
| Message-ID | <Gpa0N-4Tq1-1@gated-at.bofh.it> |
| In reply to | #107651 |
[Multipart message — attachments visible in raw view] — view raw
Hi Simon,
On Sat, Apr 22, 2023 at 11:41:29AM +0100, Simon McVittie wrote:
> You might reasonably say that "the maintainer of bar didn't add the
> correct Breaks/Replaces on foo" is a RC bug in bar - and it is! - but
> judging by the number of "missing Breaks/Replaces" bug reports that have
> to be opened by unstable users (sometimes me), it's a very easy mistake
> to make.
That number seemed quite vague to me and I wanted to get a better handle
on it. The rough idea here should be that we have some package from
bullseye and "upgrade" it to a different package from bookworm.
Generating useful candidates for this can be done using Contents. Given
candidates, I've attached a validation script:
./check_conflicts.sh $OLDPKG bullseye $NEWPKG bookworm
In order to draw value from it, the output must be parsed. The exit code
can be non-zero for various reasons. As for candidate generation, I
think one can either just try them all (which takes a bit longer on the
validation phase) or reduce their number by ignoring existing
Breaks+Replaces, but I haven't found an elegant solution for the latter
yet.
In any case, unstable has around:
* 5700 Breaks
* 6500 Replaces
* 100 unpack errors due to missing Breaks+Replaces
That latter number has just been turned into rc bugs...
So maybe it isn't as bad as we think it is, but it definitely is an
aspect that may require a more automated solution.
In any case, that also gives us a rough idea on how many Breaks+Replaces
we'd have to convert to Conflicts. 6000 likely is an upper bound. I
expect that it is probably below 1000 since we can ignore conflicting
paths that reside below /usr only. I'm not sure whether these numbers
argue in favour or against the projected approach.
Helmut
[toc] | [prev] | [next] | [standalone]
| From | James Addison <jay@jp-hosting.net> |
|---|---|
| Date | 2023-04-28 16:00 +0200 |
| Message-ID | <GpwNH-57zR-3@gated-at.bofh.it> |
| In reply to | #107707 |
On Thu, 27 Apr 2023 at 14:37, Helmut Grohne <helmut@subdivi.de> wrote: > > Hi Simon, > > On Sat, Apr 22, 2023 at 11:41:29AM +0100, Simon McVittie wrote: > > You might reasonably say that "the maintainer of bar didn't add the > > correct Breaks/Replaces on foo" is a RC bug in bar - and it is! - but > > judging by the number of "missing Breaks/Replaces" bug reports that have > > to be opened by unstable users (sometimes me), it's a very easy mistake > > to make. > > That number seemed quite vague to me and I wanted to get a better handle > on it. The rough idea here should be that we have some package from > bullseye and "upgrade" it to a different package from bookworm. > Generating useful candidates for this can be done using Contents. Given > candidates, I've attached a validation script: > > ./check_conflicts.sh $OLDPKG bullseye $NEWPKG bookworm > > In order to draw value from it, the output must be parsed. The exit code > can be non-zero for various reasons. As for candidate generation, I > think one can either just try them all (which takes a bit longer on the > validation phase) or reduce their number by ignoring existing > Breaks+Replaces, but I haven't found an elegant solution for the latter > yet. > > In any case, unstable has around: > * 5700 Breaks > * 6500 Replaces > * 100 unpack errors due to missing Breaks+Replaces > > That latter number has just been turned into rc bugs... Hi Helmut, To make sure we don't miss any packages out accidentally: could you confirm that those hundred-or-so errors occurred from 27 or so distinct packages? (looking at RC bugs created within the past week, I currently find 27 bugs with 'Breaks+Replaces' in the title) https://udd.debian.org/bugs.cgi?release=na&merged=ign&keypackages=only&fnewer=only&fnewerval=7&flastmodval=7&rc=1&cpopcon=1&chints=1&ckeypackage=1&ctags=1&cdeferred=1&caffected=1&sortby=last_modified&sorto=asc&format=html#results Thanks, James
[toc] | [prev] | [next] | [standalone]
| From | Jochen Sprickerhof <jspricke@debian.org> |
|---|---|
| Date | 2023-04-28 19:00 +0200 |
| Message-ID | <GpzBT-59fy-5@gated-at.bofh.it> |
| In reply to | #107723 |
[Multipart message — attachments visible in raw view] — view raw
Hi James, * James Addison <jay@jp-hosting.net> [2023-04-28 14:54]: >To make sure we don't miss any packages out accidentally: could you >confirm that those hundred-or-so errors occurred from 27 or so >distinct packages? > >(looking at RC bugs created within the past week, I currently find 27 >bugs with 'Breaks+Replaces' in the title) > >https://udd.debian.org/bugs.cgi?release=na&merged=ign&keypackages=only&fnewer=only&fnewerval=7&flastmodval=7&rc=1&cpopcon=1&chints=1&ckeypackage=1&ctags=1&cdeferred=1&caffected=1&sortby=last_modified&sorto=asc&format=html#results That's only key packages. Here is the full list: https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;include=subject%3Amissing+Breaks%2BReplaces;submitter=helmut%40subdivi.de Cheers Jochen
[toc] | [prev] | [next] | [standalone]
| From | James Addison <jay@jp-hosting.net> |
|---|---|
| Date | 2023-04-28 19:20 +0200 |
| Message-ID | <GpzVf-59By-1@gated-at.bofh.it> |
| In reply to | #107724 |
On Fri, 28 Apr 2023 at 17:52, Jochen Sprickerhof <jspricke@debian.org> wrote: > > Hi James, > > * James Addison <jay@jp-hosting.net> [2023-04-28 14:54]: > >To make sure we don't miss any packages out accidentally: could you > >confirm that those hundred-or-so errors occurred from 27 or so > >distinct packages? > > > >(looking at RC bugs created within the past week, I currently find 27 > >bugs with 'Breaks+Replaces' in the title) > > > >https://udd.debian.org/bugs.cgi?release=na&merged=ign&keypackages=only&fnewer=only&fnewerval=7&flastmodval=7&rc=1&cpopcon=1&chints=1&ckeypackage=1&ctags=1&cdeferred=1&caffected=1&sortby=last_modified&sorto=asc&format=html#results > > That's only key packages. Here is the full list: > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;include=subject%3Amissing+Breaks%2BReplaces;submitter=helmut%40subdivi.de > > Cheers Jochen Ah, typical user error from me. Anyway - glad to find that they've all been filed. Thank you, Jochen!
[toc] | [prev] | [next] | [standalone]
| From | Helmut Grohne <helmut@subdivi.de> |
|---|---|
| Date | 2023-04-22 13:00 +0200 |
| Message-ID | <Gnj8d-3IHC-1@gated-at.bofh.it> |
| In reply to | #107646 |
Hi Luca, 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? 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. Helmut
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <luca.boccassi@gmail.com> |
|---|---|
| Date | 2023-04-22 14:30 +0200 |
| Message-ID | <Gnkxj-3JHS-1@gated-at.bofh.it> |
| In reply to | #107653 |
On Sat, 22 Apr 2023 at 11:50, Helmut Grohne <helmut@subdivi.de> wrote: > > Hi Luca, > > 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. > 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. Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Helmut Grohne <helmut@subdivi.de> |
|---|---|
| Date | 2023-04-25 21:10 +0200 |
| Message-ID | <Gowd3-4u2x-17@gated-at.bofh.it> |
| In reply to | #107655 |
[Multipart message — attachments visible in raw view] — view raw
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. And while this sounds super ugly in the 1% of cases, it's a complexity that maybe isn't necessary at all and we can remove it after trixie unlike the complexity being added in DEP 17. In order to better understand the mechanics at hand (and due to Simon Richter's call for test cases), I sat down and wrote some. So in this mail you find 4 files attached: * runtest.sh is a wrapper script to run each case inside a fresh chroot created by mmdebstrap (as you don't want to mess your system). * case1.sh demonstrates the file loss problem with Breaks+Replaces and thus fails. * case2.sh demonstrates how Conflicts fix the problem. * case3.sh demonstrates how diversions fix the problem. In sincerely hope that this fixed-up plan doesn't have any serious issues. If you find any please tell. And before closing this mail, I would like to express my gratitude and thanks to Emilio Pozuelo Monfort for enduring me in numerous discussions on this matter and providing so many of the key insights captured in this mail. Helmut
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2023-04-25 22:40 +0200 |
| Message-ID | <GoxC9-4uL5-1@gated-at.bofh.it> |
| In reply to | #107675 |
On Tue, 25 Apr 2023 at 20:07, Helmut Grohne <helmut@subdivi.de> wrote: > > 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. It was a while ago, but from my recollection it did check both things, and it did fail the run. I'll check again when I have a moment (or better: MRs welcome ;-) ). Did you run it with any specific cases/packages to check this? > 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. Not quite, from my point of view I don't see a problem with keeping the moratorium in place for bookworm, personally. In practice, it would mean it applies to everything that currently ships files in bin/sbin/lib, as all of those are moved automatically and thus can no longer move to another package at the same time, which is of course a non-trivial constraint. But it sounds like you came up with an even better way: > 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. > > And while this sounds super ugly in the 1% of cases, it's a complexity > that maybe isn't necessary at all and we can remove it after trixie > unlike the complexity being added in DEP 17. > > In order to better understand the mechanics at hand (and due to Simon > Richter's call for test cases), I sat down and wrote some. So in this > mail you find 4 files attached: > * runtest.sh is a wrapper script to run each case inside a fresh > chroot created by mmdebstrap (as you don't want to mess your system). > * case1.sh demonstrates the file loss problem with Breaks+Replaces and > thus fails. > * case2.sh demonstrates how Conflicts fix the problem. > * case3.sh demonstrates how diversions fix the problem. > > In sincerely hope that this fixed-up plan doesn't have any serious > issues. If you find any please tell. > > And before closing this mail, I would like to express my gratitude and > thanks to Emilio Pozuelo Monfort for enduring me in numerous discussions > on this matter and providing so many of the key insights captured in > this mail. Brilliant! Would never have thought of using divert like that. So, what work would need to happen to make this reality? Do we need tooling/scripts/build changes to support the divert scheme, or is it "simply" a matter of documenting and testing? Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Raphael Hertzog <hertzog@debian.org> |
|---|---|
| Date | 2023-04-26 15:20 +0200 |
| Message-ID | <GoNdT-4FcV-1@gated-at.bofh.it> |
| In reply to | #107676 |
On Tue, 25 Apr 2023, Luca Boccassi wrote: > Brilliant! Would never have thought of using divert like that. +1 Nice trick. > So, what work would need to happen to make this reality? Do we need > tooling/scripts/build changes to support the divert scheme, or is it > "simply" a matter of documenting and testing? I would suggest to implement it with "dpkg-maintscript-helper" and document what needs to be documented as part of the associated manual page documentation. After all it's a hack to work around a dpkg limitation and it fits well with the purpose of that helper tool. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org> ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
[toc] | [prev] | [next] | [standalone]
| From | Simon Richter <sjr@debian.org> |
|---|---|
| Date | 2023-04-26 11:20 +0200 |
| Message-ID | <GoJtD-4CNn-3@gated-at.bofh.it> |
| In reply to | #107675 |
Hi,
On Tue, Apr 25, 2023 at 09:07:28PM +0200, Helmut Grohne wrote:
> 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.
Yes, the relevant code at
https://github.com/guillemj/dpkg/blob/main/src/main/unpack.c#L749
already handles moving a file inside the same package, and that has
existed for some time, that's why I use two packages for the PoC.
I have not looked for more issues beyond that, so there might be others
lurking in the depths of this code.
What I'm mostly concerned about (read: have not verified either way)
with /lib/ld.so and /bin/sh is what happens when dpkg learns of /bin and
/lib as symlinks -- because right now, the symlinks created by usrmerge
are protected by the rule that if dpkg expects a directory and finds a
symlink, that is fine because that is obviously an action taken by the
admin.
But if dpkg sees a package containing these as symlinks, then this is
entered into the dpkg database, and subject to conflict resolution, and
for that, a separate rule exists that directory-symlink conflicts are
resolved in favour of the directory, so the interaction between a newer
base-files packages shipping /lib as a symlink and an older or
third-party package containing /lib as a directory (e.g. a kernel
package from a hosting provider) could overwrite the /lib symlink.
It might be possible to avoid that by never shipping /lib as a symlink
and always creating it externally, but I still think that's kind of
wobbly.
> 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.
O_O
Yes. Hahahahaha yes.
Brittle, but it could work. What is a bit annoying is that we'd have to
keep this for an entire cycle.
Simon
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2023-04-26 11:40 +0200 |
| Message-ID | <GoJMZ-4CTY-1@gated-at.bofh.it> |
| In reply to | #107679 |
On Wed, 26 Apr 2023 at 10:11, Simon Richter <sjr@debian.org> wrote: > > Hi, > > On Tue, Apr 25, 2023 at 09:07:28PM +0200, Helmut Grohne wrote: > > > 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. > > Yes, the relevant code at > > https://github.com/guillemj/dpkg/blob/main/src/main/unpack.c#L749 > > already handles moving a file inside the same package, and that has > existed for some time, that's why I use two packages for the PoC. > > I have not looked for more issues beyond that, so there might be others > lurking in the depths of this code. > > What I'm mostly concerned about (read: have not verified either way) > with /lib/ld.so and /bin/sh is what happens when dpkg learns of /bin and > /lib as symlinks -- because right now, the symlinks created by usrmerge > are protected by the rule that if dpkg expects a directory and finds a > symlink, that is fine because that is obviously an action taken by the > admin. > > But if dpkg sees a package containing these as symlinks, then this is > entered into the dpkg database, and subject to conflict resolution, and > for that, a separate rule exists that directory-symlink conflicts are > resolved in favour of the directory, so the interaction between a newer > base-files packages shipping /lib as a symlink and an older or > third-party package containing /lib as a directory (e.g. a kernel > package from a hosting provider) could overwrite the /lib symlink. > > It might be possible to avoid that by never shipping /lib as a symlink > and always creating it externally, but I still think that's kind of > wobbly. IMHO we should not ship the top-level symlinks in a package. The reason for that is to allow the use case where /usr is a separate vendor partition and / is either a luks volume or a tmpfs, and thus the top-level symlinks are ephemeral and re-created on boot on the fly. If they were part of a package, that would get awkward to say the least. I really would like to move toward the direction of having exclusively /usr and /etc shipped in data.tar, and everything else created locally as needed, and that includes files in /. Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Sven Joachim <svenjoac@gmx.de> |
|---|---|
| Date | 2023-04-26 18:30 +0200 |
| Message-ID | <GoQbL-4GZ1-5@gated-at.bofh.it> |
| In reply to | #107680 |
On 2023-04-26 10:34 +0100, Luca Boccassi wrote:
> On Wed, 26 Apr 2023 at 10:11, Simon Richter <sjr@debian.org> wrote:
>>
>> What I'm mostly concerned about (read: have not verified either way)
>> with /lib/ld.so and /bin/sh is what happens when dpkg learns of /bin and
>> /lib as symlinks -- because right now, the symlinks created by usrmerge
>> are protected by the rule that if dpkg expects a directory and finds a
>> symlink, that is fine because that is obviously an action taken by the
>> admin.
>>
>> But if dpkg sees a package containing these as symlinks, then this is
>> entered into the dpkg database, and subject to conflict resolution, and
>> for that, a separate rule exists that directory-symlink conflicts are
>> resolved in favour of the directory, so the interaction between a newer
>> base-files packages shipping /lib as a symlink and an older or
>> third-party package containing /lib as a directory (e.g. a kernel
>> package from a hosting provider) could overwrite the /lib symlink.
No, this does not change anything. The dpkg database currently does not
even record if a pathname in it corresponds to a symlink, a directory or
something else. See also Policy §6.6.4 :
,----
| A directory will never be replaced by a symbolic link to a directory or
| vice versa; instead, the existing state (symlink or not) will be left
| alone and "dpkg" will follow the symlink if there is one.
`----
>> It might be possible to avoid that by never shipping /lib as a symlink
>> and always creating it externally, but I still think that's kind of
>> wobbly.
>
> IMHO we should not ship the top-level symlinks in a package. The
> reason for that is to allow the use case where /usr is a separate
> vendor partition and / is either a luks volume or a tmpfs, and thus
> the top-level symlinks are ephemeral and re-created on boot on the
> fly. If they were part of a package, that would get awkward to say the
> least.
> I really would like to move toward the direction of having exclusively
> /usr and /etc shipped in data.tar, and everything else created locally
> as needed, and that includes files in /.
This means that you need special code in dpkg to preserve these top
level symlinks, as otherwise they are going to disappear with the last
package that contained these as directories, instantly hosing your
installation. I am pretty sure the dpkg maintainer will not like this.
Cheers,
Sven
[toc] | [prev] | [next] | [standalone]
| From | Raphael Hertzog <hertzog@debian.org> |
|---|---|
| Date | 2023-05-02 12:40 +0200 |
| Message-ID | <GqVAl-612L-1@gated-at.bofh.it> |
| In reply to | #107679 |
Hello, On Wed, 26 Apr 2023, Simon Richter wrote: > > 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. > > Yes, the relevant code at > > https://github.com/guillemj/dpkg/blob/main/src/main/unpack.c#L749 > > already handles moving a file inside the same package, and that has > existed for some time, that's why I use two packages for the PoC. Hum... why aren't we improving this part of the code? We don't want to stat all the files in all packages but we could do better: if we are about to remove an old file that is available through a symlinked directory, we could check the new name of the file and see if it's available in some package... and if yes just forget the file without removing it. This file removal is the reason of the moratorium and incuring some extra cost in some specific cases (installation through directory symlinks which is not the default case, and would not affect us after the migration is complete) seems certainly fair. The cost of analyzing directory components is a cost that we will have on all dpkg invocations but it doesn't seem unreasonable to me. We could also restrict it to the top-level directories to make it negligible as this is the only transition that we care about here. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org> ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
[toc] | [prev] | [next] | [standalone]
Page 1 of 10 [1] 2 3 … 10 Next page →
Back to top | Article view | linux.debian.devel
csiph-web