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 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2023-06-09 12:40 +0200 |
| Subject | Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) |
| Message-ID | <GEHHb-eIjR-1@gated-at.bofh.it> |
| In reply to | #108148 |
On Fri, 9 Jun 2023 at 10:53, Raphael Hertzog <hertzog@debian.org> wrote: > > On Fri, 09 Jun 2023, Marco d'Itri wrote: > > On Jun 08, Raphael Hertzog <hertzog@debian.org> 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? > > It could be even easier: base-files could be unpacked once without > > running the maintainer scripts and then "reinstalled" again later as > > usual. > > I think you are missing the point here, that only works if the package is > shipping the symlinks. And the idea is to not do this immediately because > it breaks debootstrap: if I understood correctly unpacking base-files > with the symlinks would fail if debootstrap had already pre-created those > symlinks (due to a -k option that we should get rid of in > /usr/share/debootstrap/scripts/debian-common). > > Hence the special maintainer script to create the required symlinks > without relying on /bin/sh or any dynamically linked executable. Yes I think this will necessarily require another round of debootstrap changes once we've locked in on what we want to do, and go via the various -p-u queues. I'm pretty sure some buildds will still be stuck on Buster for example. I've done this last year and I'm happy to do it again once we have a plan. Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Bjørn Mork <bjorn@mork.no> |
|---|---|
| Date | 2023-06-09 13:10 +0200 |
| Subject | Re: booststrapping /usr-merged systems |
| Message-ID | <GEIad-eIJq-1@gated-at.bofh.it> |
| In reply to | #108143 |
Marco d'Itri <md@Linux.IT> writes: > as we all know every Debian maintainer can veto any systemic changes > that they do not like. I don't think qusr-merge would not have happened if this was true. And I believe you know that very well. I find your remark disrespectful. And I'm trying hard to assume good faith here. Please help me. What are you trying to achieve by it? Was it meant as a joke? If so, then it was a bit misplaced I'm afraid. Maybe you should re-read https://www.debian.org/code_of_conduct ? Bjørn
[toc] | [prev] | [next] | [standalone]
| From | Marco d'Itri <md@Linux.IT> |
|---|---|
| Date | 2023-06-09 13:40 +0200 |
| Subject | Re: booststrapping /usr-merged systems |
| Message-ID | <GEIDf-eIUC-5@gated-at.bofh.it> |
| In reply to | #108151 |
[Multipart message — attachments visible in raw view] — view raw
On Jun 09, Bjørn Mork <bjorn@mork.no> wrote: > > as we all know every Debian maintainer can veto any systemic changes > > that they do not like. > I don't think qusr-merge would not have happened if this was true. And > I believe you know that very well. Actually merging /usr happened in a suboptimal way because I had to work around this lack of collaboration, so yes: this is true. It happened, but despite the vetoes. -- ciao, Marco
[toc] | [prev] | [next] | [standalone]
| From | Johannes Schauer Marin Rodrigues <josch@debian.org> |
|---|---|
| Date | 2023-06-09 17:40 +0200 |
| Subject | Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) |
| Message-ID | <GEMnx-eLbI-13@gated-at.bofh.it> |
| In reply to | #108143 |
[Multipart message — attachments visible in raw view] — view raw
Quoting Marco d'Itri (2023-06-09 09:41:43) > On Jun 08, Raphael Hertzog <hertzog@debian.org> wrote: > > And creating the required symlinks would be done by those (standalone) > > maintainer scripts... > > > > I don't know if we already have some rule/invariant in the configuration > > order of the unpacked packages, but I doubt so. > Indeed, this would be very simple and it has already been proposed. > But somebody then complained that special-casing a package would violate > the design contraints he self-imposed to his own image building tool, > and as we all know every Debian maintainer can veto any systemic changes that > they do not like. I definitely complained about special-casing a package because it would violate the design contract for my own image building tool. You would not by any chance be talking about me in your last message, would you? Anyway, great communication style. This will totally help bringing us all together to create a great operating system. Very productive. I already feel a lot more motivated to discuss technical matters with you. Now who do I have to talk to in case I'd really like to veto something? Thanks! cheers, josch
[toc] | [prev] | [next] | [standalone]
| From | Helmut Grohne <helmut@subdivi.de> |
|---|---|
| Date | 2023-06-09 15:30 +0200 |
| Subject | Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) |
| Message-ID | <GEKlH-eK00-3@gated-at.bofh.it> |
| In reply to | #108123 |
Hi Raphaël, On Thu, Jun 08, 2023 at 10:46:24AM +0200, Raphael 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? Thanks for putting effort into this questions. You already figured that this poses a problem to dpkg calling the maintainer script. Let me add two further observations to further understand the solution space here. dpkg has a --root flag and can be called externally. This is something mmdebstrap already uses in some modes. That way, we avoid the issue you presented for dpkg itself. Unfortunately, we cannot assume presence of dpkg outside the chroot as debootstrap supports running on non-Debian systems, so the --root flag doesn't actually help us here. The other aspect is that maintainer scripts that are not interpreted break chrootless foreign architecture bootstrap as the base-files.preinst would be an executable that the processor cannot execute. In a vague reply to the other messages as well: I repeatedly got the feedback that I have not sufficiently exploited the solution space. I hear you. My lack of replies here shall indicate that I'm not done. I have a vague sketch that seems to kinda work out for everything, but maybe it still has some problems that I don't see yet. Let me summarize it even though this very much is unfinished. Given my earlier categorization of the solution space, this is a category 2 solution addressing many of the problems mentioned there. Update debootstrap (in bookworm and unstable) to create the symbolic links after unpacking rather than before while still doing it before running any maintainer scripts. This enables us to ship the symbolic links in some data.tar while keeping bootstraps of bookworm and earlier working as before. Add a new package usrmerge-support (or whatever). It is a bit similar to multiarch-support: It must not have any dependencies or pre-dependencies. It will not have files, but maintainer scripts. Those scripts set up protective diversions on behalf of base-files for the symbolic links that cause aliasing. Then base-files will issue a Pre-Depends on usrmerge-support (but not yet ship symlinks). I initially thought, this could be part of usr-is-merged, but then base-files would pull that and standard mmdebstrap would no longer pull usrmerge and break. So it really needs to be a separate package. Anyway, once we have protective diversions, we can move files without risking that dpkg deletes the symbolic links. Then we can actually perform that move of files to their canonical locations except for a small set of locations including dash, bash, libc6, and util-linux (maybe not exhaustive). [There is a lot of missing detail about non-bootstrap aspects here.] Once all essential packages (but the exceptions) have no files left in aliased locations, we can upload base-files adding the symlinks together with the packages previously kept unmodified in one dinstall. Before that dinstall, things will continue to work normally. The protective diversions will not affect unpacking, because dpkg only performs exact matches on diversions. After that dinstall, base-files will create the symlinks and things will hopefully work (because the patched debootstrap only creates them after the initial unpack). This still is a lot of wishful thinking. I've prototyped parts of this, but not the entire story. I'm pretty sure it'll not work out as written here, but maybe some adaption of it will unless insurmountable issues pop up. For instance, debootstrap --variant=buildd (which currently implies --no-merged-usr) will need a second thought. You may now tell me why this is utter nonsense and why it cannot work at all. Thanks. Helmut
[toc] | [prev] | [next] | [standalone]
| From | Johannes Schauer Marin Rodrigues <josch@debian.org> |
|---|---|
| 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-5@gated-at.bofh.it> |
| In reply to | #108155 |
[Multipart message — attachments visible in raw view] — view raw
Hi, Quoting Helmut Grohne (2023-06-09 15:22:39) > Add a new package usrmerge-support (or whatever). It is a bit similar to > multiarch-support: It must not have any dependencies or pre-dependencies. It > will not have files, but maintainer scripts. Those scripts set up protective > diversions on behalf of base-files for the symbolic links that cause > aliasing. Then base-files will issue a Pre-Depends on usrmerge-support (but > not yet ship symlinks). I initially thought, this could be part of > usr-is-merged, but then base-files would pull that and standard mmdebstrap > would no longer pull usrmerge and break. So it really needs to be a separate > package. Anyway, once we have protective diversions, we can move files > without risking that dpkg deletes the symbolic links. > > Then we can actually perform that move of files to their canonical > locations except for a small set of locations including dash, bash, > libc6, and util-linux (maybe not exhaustive). [There is a lot of missing > detail about non-bootstrap aspects here.] > > Once all essential packages (but the exceptions) have no files left in > aliased locations, we can upload base-files adding the symlinks together > with the packages previously kept unmodified in one dinstall. Before > that dinstall, things will continue to work normally. The protective > diversions will not affect unpacking, because dpkg only performs exact > matches on diversions. After that dinstall, base-files will create the > symlinks and things will hopefully work (because the patched debootstrap only > creates them after the initial unpack). if I understand that plan correctly, the usrmerge-support package setting up diversions is only necessary because you want to avoid having to do the move to /usr of *all* affected packages in the essential set in a single dinstall? Is that correct? If yes, how many source packages are we have to be modified part from base-files, dash, bash, libc6, and util-linux? Is it just these? audit bzip2 coreutils debianutils dpkg gcc-13 grep gzip hostname libcap2 libcap-ng libgpg-error libselinux libxcrypt ncurses pam sed shadow sysvinit tar xz-utils zlib Would it be too much to prepare patches for all of these, test that everything works with some QA setup and then NMU all 22 source packages with pre-approved patches in a single dinstall? Would that avoid having to temporarily go via a usrmerge-support package? Thanks! cheers, josch
[toc] | [prev] | [next] | [standalone]
| From | Helmut Grohne <helmut@subdivi.de> |
|---|---|
| Date | 2023-06-09 18:30 +0200 |
| Subject | Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) |
| Message-ID | <GEN9T-eLHh-1@gated-at.bofh.it> |
| In reply to | #108158 |
Hi Johannes, On Fri, Jun 09, 2023 at 05:47:56PM +0200, Johannes Schauer Marin Rodrigues wrote: > if I understand that plan correctly, the usrmerge-support package setting up > diversions is only necessary because you want to avoid having to do the move to > /usr of *all* affected packages in the essential set in a single dinstall? Is > that correct? This is not correct. In bookworm -> trixie upgrade scenario, we intend to move all the files from / to /usr. Now we look into how this happens focus on one particular symlink, without loss of generality choose /bin. Since /bin is no longer in the dpkg database at the end of the upgrade, some package must be the last one to contain /bin. When upgrading (or removing that package), dpkg will attempt to remove /bin (which in its opinion is an empty directory and the last consumer is releasing it). However, since dpkg has no clue about file types, it doesn't actually know that this is a directory and takes care of the /bin -> /usr/bin symlink using unlink(). And this is where /bin vanishes. Oops. So the idea here is to add a protective diversion for /bin such that removing /bin instead removes some path we don't care about. The important thing now is that every package that moves stuff from /bin to /usr/bin needs to ensure that this diversion exists. We can achieve that in one of two ways. Either that some package (and with that I mean every package that ships stuff in /bin, because we cannot predict which package will be last) gains a preinst that sets up this diversion (on behalf of base-files) or it Pre-Depends on some package that handles setting up this diversion. It seems rather obvious that we might just have a versioned "Pre-Depends: base-files (>= version that introduces the diversion)", but then we get a pre-dependency loop from base-files via an awk implementation to libc6 and then (via this new Pre-Depends) back to base-files. So base-files cannot be the package that we list in Pre-Depends here. And this is where usrmerge-support comes into the picture. Any package that moves stuff out of one of the aliased directories gains a Pre-Depends: usrmerge-support to protect the aliasing symlinks from deletion. Please note that this hasn't been obvious to me at all. I totally didn't see this pre-dependency loop coming until dpkg told me when I actually tried this. So this usrmerge-support package very much is not for reducing that set that we have to upload in one dinstall, but for making smooth upgrades work at all. This really is an important detail and I'm sorry for having missed it in my previous mail. Thanks for asking. > If yes, how many source packages are we have to be modified part from > base-files, dash, bash, libc6, and util-linux? Given the above, I think this no longer is relevant. > Would it be too much to prepare patches for all of these, test that everything > works with some QA setup and then NMU all 22 source packages with pre-approved > patches in a single dinstall? Would that avoid having to temporarily go via a > usrmerge-support package? I have considered this approach and if it gains us something I definitely see it as something to consider, but given the above, it doesn't save us from usrmerge-support. The other thing that we need usrmerge-support for is the dpkg-divert wrapper. Any package that contains an aliased diversion or moves a diverted file from an aliased location will likewise have to gain a pre-dependency on usrmerge-support. Again, we cannot do this in usr-is-merged, because that would kick usrmerge out of the default essential set and thus break mmdebstrap. Helmut
[toc] | [prev] | [next] | [standalone]
| From | Richard Laager <rlaager@debian.org> |
|---|---|
| Date | 2023-06-09 20:10 +0200 |
| Subject | Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) |
| Message-ID | <GEOIF-eMHZ-7@gated-at.bofh.it> |
| In reply to | #108161 |
[Multipart message — attachments visible in raw view] — view raw
On 2023-06-09 11:26, Helmut Grohne wrote: > When upgrading (or > removing that package), dpkg will attempt to remove /bin (which in its > opinion is an empty directory and the last consumer is releasing it). > However, since dpkg has no clue about file types, it doesn't actually > know that this is a directory and takes care of the /bin -> /usr/bin > symlink using unlink(). And this is where /bin vanishes. Oops. This might be a dumb question, but could we just special-case this? That is, dpkg would simply not remove /bin specifically? If the list of directories is small, known, and relatively fixed (e.g. /bin, /usr/bin, /lib), that might be workable. -- Richard
[toc] | [prev] | [next] | [standalone]
| From | Helmut Grohne <helmut@subdivi.de> |
|---|---|
| Date | 2023-06-09 20:50 +0200 |
| Subject | Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) |
| Message-ID | <GEPlo-eMUw-5@gated-at.bofh.it> |
| In reply to | #108164 |
Hi Richard, On Fri, Jun 09, 2023 at 01:07:13PM -0500, Richard Laager wrote: > On 2023-06-09 11:26, Helmut Grohne wrote: > > When upgrading (or > > removing that package), dpkg will attempt to remove /bin (which in its > > opinion is an empty directory and the last consumer is releasing it). > > However, since dpkg has no clue about file types, it doesn't actually > > know that this is a directory and takes care of the /bin -> /usr/bin > > symlink using unlink(). And this is where /bin vanishes. Oops. > > This might be a dumb question, but could we just special-case this? That is, > dpkg would simply not remove /bin specifically? If the list of directories > is small, known, and relatively fixed (e.g. /bin, /usr/bin, /lib), that > might be workable. Even if this was a dumb question, it's these kind of questions that - surprisingly often - lead to new insights. So thanks for asking. I caution that this protection mechanism of symlinks is a property of the installation and not of dpkg. Depending on what dpkg is operating on, we expect it to handle this or not. So we'd need a way to tell whether an installation needs this kind of special handling. Anyway, let's for now just assume that magically dpkg would magically save those symlinks when we want to save them. Now any package that moves files from / to /usr, needs to ensure that the dpkg doing that move is recent. That's a dependency we cannot express in theory. David Kalnischkies spent some time going into detail[1] about this aspect. I think the bottom line is that for all practical purposes we're probably fine if everything that moves also gains a Pre-Depends on dpkg. Except that dpkg Pre-Depends on libc6, which would now Pre-Depends: dpkg and we're back to our Pre-Depends loop. So now we say "screw it" and let libc6 get a pass without this Pre-Depends, because so many packages already have a Pre-Dependency on dpkg, it'll probably get upgraded early and what could possibly go wrong? On amd64, we'd upgrade libc6 before dpkg and then /lib64 would go missing, because libc6 already is the last package that ships files in /lib64. So really, libc6 is one of the few packages that really must depend on that fixed dpkg. It also is one of the few packages that really cannot. As we cannot get out of this loop, we consider stretching the transition over two releases. For trixie, we just update dpkg without moving files and then for the trixie -> forky upgrade, we know (since we forbid skip upgrades) that dpkg is fixed and then it actually works out without this mess of Pre-Depends on dpkg. My impression is that we'd like to have this done sooner rather than later. At this time, the protective diversion seems like a fairly easy and reliable mitigation with little downsides (except for having a new transitively essential package) that helps us move forward faster. Please don't stop asking. The chances that something about this is wrong or missing something is significantly non-zero. I hope that this kind of peer-review will get us to a solution that actually works in practice. Helmut [1] https://lists.debian.org/20230503130026.ixu4zlymo4fykdru@crossbow
[toc] | [prev] | [next] | [standalone]
| From | Helmut Grohne <helmut@subdivi.de> |
|---|---|
| Date | 2023-06-09 22:20 +0200 |
| Subject | Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) |
| Message-ID | <GEQKt-eNTV-1@gated-at.bofh.it> |
| In reply to | #108165 |
Hi Richard,
On Fri, Jun 09, 2023 at 02:42:25PM -0500, Richard Laager wrote:
> Is the broader context here that this is an alternative to teaching dpkg
> about aliasing? That is, we just arrange the transition correctly such that
> we get out of the aliased situation as part of upgrading to trixie?
Yes, I think the idea that we are mostly exploring now is not teaching
dpkg about aliasing and rather move all the files to their canonical
location such that there no longer is any aliasing that dpkg would have
to deal with.
I don't think this is complete consensus at this time, but the majority
of discussion participants appear to favour this approach.
> Because you want to support non-usr-merged systems, e.g. for derivatives?
dpkg is used in any different contexts. A very simple example of a
non-merged system would be Debian stretch. For another dpkg really is
being used for things that are not based on Debian. While it is the
Debian package manager, it has uses beyond dpkg has (thus far) stayed
away from imposing policy on the filesystem layout.
> They aren't going to want to delete /bin either, so I don't see how a
> special-case preventing deletion of /bin would be problematic.
Indeed. However, if you actually manage to trigger this, it can be very
surprising. Your hard coded list would also contain /lib32, /libx32 and
/libo32. Then you install some mipsen packages, remove them and wonder
why /libo32 does not go away. piuparts is definitely unhappy at this
point. I am quite sure that this behaviour would break something. What I
am not sure about is whether accepting such breakage is a reasonable
trade-off.
> Am I understanding the problem correctly?
I confirm.
> What would happen if, for trixie only, bin:libc6 shipped two identical
> copies of ld-linux-x86-64.so.2, one in each of /lib64 and /usr/lib64?
That's an interesting idea. Do note that we don't actually have to ship
ld-linux in both locations. We can actually move it in a safe way
(unless we also move it between packages, which we don't). So let me
change that to: We keep /lib64 (the directory) in addition to
/usr/lib64. Keeping the directory prevents dpkg from deleting the
symlink (as it doesn't know about the filetype).
> Then at step 2, /lib64 does not get deleted and nothing breaks.
Confirmed (with the simplified variant).
> Later, whatever replaces /lib64 with a symlink needs to deal with this, but
> that's not significantly different than whatever it was going to do anyway,
> right? Just do this:
>
> 1. Whatever safety checks are appropriate.
> 2. Unless already verified to be identical by #1, hardlink
> /lib64/ld-linux-x86-64.so.2 to /usr/lib64/ld-linux-x86-64.so.2. This might
> be just a particular instance of the more general case of hardlink
> everything from /lib64 into /usr/lib64.
> 3. Unlink everything from /lib64.
> 4. Unlink /lib64.
> 5. Symlink /lib64 to /usr/lib64
I think we start from the premise that /lib64 already is a symlink and
as long as libc6 actually ships /lib64 (even if empty), dpkg won't
delete it. What we will not get here is getting rid of the aliasing and
we will also be unable to ship /lib64 as a symlink in any data.tar
(since that would be a directory vs symlink conflict, which has
unpack-order-dependent behaviour, which is bad).
> However, note that this cannot be a shell script, as then step 3 would
> delete /lib64/ld-linux-x86-64.so.2 and everything after that would fail.
Non-issue since we assume that bookworm is merged already.
> At that point, everything is fine, EXCEPT that dpkg now thinks it has a
> /lib64/ld-linux-x86-64.so.2 file installed, but really that is aliasing
> /usr/lib64/ld-linux-x86-64.so.2. When bin:lib6:amd64 is later upgraded (e.g.
> in forky) to a version that stops shipping /lib64/ld-linux-x86-64.so.2, dpkg
> will unlink /lib64/ld-linux-x86-64.so.2 and then everything breaks.
Simplified: dpkg thinks that it has /lib64 while it should not. When we
drop that in forky, stuff breaks.
> The fix to that is either whatever separate general case fix is being done
> for aliasing, or if the whole point is we are trying to avoid having that
> sort of thing at all, then just put in a special case that dpkg will not
> unlink /lib64/ld-linux-x86-64.so.2.
Yes, if we add that special casing to dpkg, we can remove /lib64 in forky.
> So we end up with something roughly like this in dpkg (please excuse
> syntax/pointer errors):
>
> Wherever file deletions are handled, make this change:
> - unlink(pathname);
> + special_unlink(pathname);
>
> to use this:
>
> char *SPECIAL_PATHS[] = {
> "/bin",
> "/lib",
> "/lib64",
> "/lib64/ld-linux-x86-64.so.2",
> "/sbin",
> NULL,
> }
>
> void special_unlink(const char *pathname) {
> const char **special;
> for (special = SPECIAL_PATHS ; *special ; special++) {
> if (strcmp(pathname, special) == 0) {
> return;
> }
> }
> unlink(pathname);
> }
Might work, but the list of SPECIAL_PATHS is /bin, /lib, /lib32,
/lib64, /libo32, /libx32, and /sbin and nothing else.
So yeah, I'm inclined to agree that this would technically work for
upgrades, but we'd not be closer to the bootstrap problem, because this
variant does not allow us to ship the symlinks in any data.tar for
trixie. So at the time of this writing, your this approach still looks
inferior to the variant I presented to me.
I'm definitely biased towards what I presented (cause I don't want to
make a fool of myself), so please continue pointing out issues and
alternative approaches. :)
Helmut
[toc] | [prev] | [next] | [standalone]
| From | Jeroen Dekkers <jeroen@dekkers.ch> |
|---|---|
| Date | 2023-06-11 15:40 +0200 |
| Subject | Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) |
| Message-ID | <GFtsu-fbrX-19@gated-at.bofh.it> |
| In reply to | #108166 |
On Fri, 09 Jun 2023 22:14:16 +0200, Helmut Grohne wrote: > On Fri, Jun 09, 2023 at 02:42:25PM -0500, Richard Laager wrote: > > Because you want to support non-usr-merged systems, e.g. for derivatives? > > dpkg is used in any different contexts. A very simple example of a > non-merged system would be Debian stretch. For another dpkg really is > being used for things that are not based on Debian. While it is the > Debian package manager, it has uses beyond dpkg has (thus far) stayed > away from imposing policy on the filesystem layout. Refusing to delete /bin etc. doesn't mean that dpkg imposes any policy on the filesystem layout. The change would also be small enough that it would be easy to disable it, but I can't think of any usage of dpkg for which that would be needed. > > They aren't going to want to delete /bin either, so I don't see how a > > special-case preventing deletion of /bin would be problematic. > > Indeed. However, if you actually manage to trigger this, it can be very > surprising. Your hard coded list would also contain /lib32, /libx32 and > /libo32. Then you install some mipsen packages, remove them and wonder > why /libo32 does not go away. piuparts is definitely unhappy at this > point. I am quite sure that this behaviour would break something. What I > am not sure about is whether accepting such breakage is a reasonable > trade-off. I can't really think of anything that would break with having an extra directory or symlink around. And if base-files ships the symlinks they would always be there and piuparts would be happy. > > Later, whatever replaces /lib64 with a symlink needs to deal with this, but > > that's not significantly different than whatever it was going to do anyway, > > right? Just do this: > > > > 1. Whatever safety checks are appropriate. > > 2. Unless already verified to be identical by #1, hardlink > > /lib64/ld-linux-x86-64.so.2 to /usr/lib64/ld-linux-x86-64.so.2. This might > > be just a particular instance of the more general case of hardlink > > everything from /lib64 into /usr/lib64. > > 3. Unlink everything from /lib64. > > 4. Unlink /lib64. > > 5. Symlink /lib64 to /usr/lib64 > > I think we start from the premise that /lib64 already is a symlink and > as long as libc6 actually ships /lib64 (even if empty), dpkg won't > delete it. What we will not get here is getting rid of the aliasing and > we will also be unable to ship /lib64 as a symlink in any data.tar > (since that would be a directory vs symlink conflict, which has > unpack-order-dependent behaviour, which is bad). But if all packages in trixie are changed to not ship /lib64 anymore, there wouldn't be a conflict in trixie anymore? If we have the following situation: - We change dpkg to never delete /bin, /lib, /lib32, /lib64, /libo32, /libx32, and /sbin. We can also change dpkg in bookworm to not do this so that we are sure that when upgrading to trixie we have a dpkg that won't delete any of these symlinks. - All packages in trixie are changed to have their files moved to /usr. - Base-files will include the symlinks In the case of bootstrapping no trixie package will have any files in /bin etc. so there wouldn't be a directory vs symlink conflict. From what I understood we need to change the bootstrap protocol to make sure that base-files is unpacked before anything is run so that /bin/sh and ld-linux.so are available. To me that seems to be a simple change to make and it should also be possible to make this small change in the bootstrapping tools in bookworm. In the case of upgrading we already have all the symlinks in the filesystem. Installing base-files when there are still packages installed with files in /bin etc. shouldn't be a problem as far as I understand it. And we changed dpkg to never delete the symlinks when no package ships the /bin directory anymore so it also shouldn't be a problem if all packages that used to ship /bin etc/ are upgraded before base-files is upgraded. Kind regards, Jeroen Dekkers
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2023-06-11 19:10 +0200 |
| Subject | Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) |
| Message-ID | <GFwJH-fdzL-31@gated-at.bofh.it> |
| In reply to | #108181 |
[Multipart message — attachments visible in raw view] — view raw
On Sun, 11 Jun 2023, 14:32 Jeroen Dekkers, <jeroen@dekkers.ch> wrote: > On Fri, 09 Jun 2023 22:14:16 +0200, > Helmut Grohne wrote: > > On Fri, Jun 09, 2023 at 02:42:25PM -0500, Richard Laager wrote: > > > Later, whatever replaces /lib64 with a symlink needs to deal with > this, but > > > that's not significantly different than whatever it was going to do > anyway, > > > right? Just do this: > > > > > > 1. Whatever safety checks are appropriate. > > > 2. Unless already verified to be identical by #1, hardlink > > > /lib64/ld-linux-x86-64.so.2 to /usr/lib64/ld-linux-x86-64.so.2. This > might > > > be just a particular instance of the more general case of hardlink > > > everything from /lib64 into /usr/lib64. > > > 3. Unlink everything from /lib64. > > > 4. Unlink /lib64. > > > 5. Symlink /lib64 to /usr/lib64 > > > > I think we start from the premise that /lib64 already is a symlink and > > as long as libc6 actually ships /lib64 (even if empty), dpkg won't > > delete it. What we will not get here is getting rid of the aliasing and > > we will also be unable to ship /lib64 as a symlink in any data.tar > > (since that would be a directory vs symlink conflict, which has > > unpack-order-dependent behaviour, which is bad). > > But if all packages in trixie are changed to not ship /lib64 anymore, there > wouldn't be a conflict in trixie anymore? If we have the following > situation: > > - We change dpkg to never delete /bin, /lib, /lib32, /lib64, /libo32, > /libx32, > and /sbin. We can also change dpkg in bookworm to not do this so that we > are > sure that when upgrading to trixie we have a dpkg that won't delete any > of > these symlinks. Changing dpkg is a non starter. Even assuming it's doable (it's not) it would take years of fighting before a single line of code was merged, and would require finding a new maintainer at a minimum. Are you volunteering for the job? The file move moratorium would have to remain in place for 2/3/4 releases on top of that while all of this is sorted. Helmut's idea is good because it's doable in the real world. Are there theoretical alternatives? Most likely. But let's focus on what's possible and really doable in the next month or so and get this over with, please. Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2023-06-11 19:10 +0200 |
| Subject | Re: booststrapping /usr-merged systems |
| Message-ID | <GFwJH-fdzL-15@gated-at.bofh.it> |
| In reply to | #108166 |
Helmut Grohne <helmut@subdivi.de> writes: > Indeed. However, if you actually manage to trigger this, it can be very > surprising. Your hard coded list would also contain /lib32, /libx32 and > /libo32. Then you install some mipsen packages, remove them and wonder > why /libo32 does not go away. piuparts is definitely unhappy at this > point. I am quite sure that this behaviour would break something. What I > am not sure about is whether accepting such breakage is a reasonable > trade-off. Compared to most of the problems we've discussed on these threads, this seems like a very unimportant problem and a very acceptable trade-off. We can just change puiparts to not care. It's not *idea* to have a dangling symlink that points to a nonexistent directory, to be sure, but given that normal UNIX symlink semantics treat that symlink as identical to a nonexistent file/directory unless you go out of your way to treat it as a symlink, I find it hard to imagine what specifically would break, and am therefore much less sure than you are that this would break something. (Other than QA tools like piuparts, which IMO don't count. A failing test case doesn't necessarily mean a real problem; it can mean that the assumptions the test case were written under have changed. One has to look at the specifics to see whether there is a real problem or whether the test case should be changed.) On the other, related topic, I've also been somewhat confused in this discussion why it seems like there's a long-term goal to not have any Debian package ship the /bin and /lib symlinks. I would assume we would keep those symlinks forever, and thus will always be shipping them in a package from now on (once we get to a place where it's safe to ship them in a package). In the long term, that seems like the most efficient way to prevent them from being removed, and also just seems obviously correct semantically. -- Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2023-06-11 19:30 +0200 |
| Subject | Re: booststrapping /usr-merged systems |
| Message-ID | <GFx34-fdGn-35@gated-at.bofh.it> |
| In reply to | #108182 |
On Sun, 11 Jun 2023 at 18:06, Russ Allbery <rra@debian.org> wrote: > On the other, related topic, I've also been somewhat confused in this > discussion why it seems like there's a long-term goal to not have any > Debian package ship the /bin and /lib symlinks. I would assume we would > keep those symlinks forever, and thus will always be shipping them in a > package from now on (once we get to a place where it's safe to ship them > in a package). In the long term, that seems like the most efficient way > to prevent them from being removed, and also just seems obviously correct > semantically. In the long term, there are two camps: those who would like to ship everything as package content (ie: top level symlinks in data.tar of some package, probably base-files) and those who would like packages to exclusively ship files under the vendor trees (/usr and optionally /etc) and let image builders set up required mount points, symlinks, and so on. To be clear, despite being in the latter group, I am absolutely fine with going with the first option for now to finish the transition, if it's the best and easiest way to do so, and eventually revisit it later. Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2023-06-11 20:10 +0200 |
| Subject | Re: booststrapping /usr-merged systems |
| Message-ID | <GFxFL-fe8Z-7@gated-at.bofh.it> |
| In reply to | #108184 |
Luca Boccassi <bluca@debian.org> writes: > On Sun, 11 Jun 2023 at 18:06, Russ Allbery <rra@debian.org> wrote: >> On the other, related topic, I've also been somewhat confused in this >> discussion why it seems like there's a long-term goal to not have any >> Debian package ship the /bin and /lib symlinks. I would assume we >> would keep those symlinks forever, and thus will always be shipping >> them in a package from now on (once we get to a place where it's safe >> to ship them in a package). In the long term, that seems like the most >> efficient way to prevent them from being removed, and also just seems >> obviously correct semantically. > In the long term, there are two camps: those who would like to ship > everything as package content (ie: top level symlinks in data.tar of > some package, probably base-files) and those who would like packages > to exclusively ship files under the vendor trees (/usr and optionally > /etc) and let image builders set up required mount points, symlinks, > and so on. Ah. Well, let me register my (preliminary, rebuttable) opposition to that second strategy in advance to hopefully make it clear well before it becomes an issue that there is no current project consensus to go that route and we need an actual design discussion (hopefully this time with considerably more attention paid to details) before starting down that path, if we do. (Now is not the time for that discussion; please don't try to convince me that I'm wrong at the moment. I'm only asking that people remember that this is not something we have all agreed upon.) > To be clear, despite being in the latter group, I am absolutely fine > with going with the first option for now to finish the transition, if > it's the best and easiest way to do so, and eventually revisit it later. At least at first glance, and while adding the additional rule to not delete /bin, /lib, etc. seems helpful, it looks like the correct approach to me. It also works well with the strategy that *is* a current project goal and that we *have* been working (slowly) towards, namely making dpkg aware of every file on the file system so that it has a complete picture of the resources that it's managing. -- Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2023-06-11 20:50 +0200 |
| Subject | Re: booststrapping /usr-merged systems |
| Message-ID | <GFyit-femd-3@gated-at.bofh.it> |
| In reply to | #108185 |
On Sun, 11 Jun 2023 at 19:07, Russ Allbery <rra@debian.org> wrote: > > Luca Boccassi <bluca@debian.org> writes: > > On Sun, 11 Jun 2023 at 18:06, Russ Allbery <rra@debian.org> wrote: > > >> On the other, related topic, I've also been somewhat confused in this > >> discussion why it seems like there's a long-term goal to not have any > >> Debian package ship the /bin and /lib symlinks. I would assume we > >> would keep those symlinks forever, and thus will always be shipping > >> them in a package from now on (once we get to a place where it's safe > >> to ship them in a package). In the long term, that seems like the most > >> efficient way to prevent them from being removed, and also just seems > >> obviously correct semantically. > > > In the long term, there are two camps: those who would like to ship > > everything as package content (ie: top level symlinks in data.tar of > > some package, probably base-files) and those who would like packages > > to exclusively ship files under the vendor trees (/usr and optionally > > /etc) and let image builders set up required mount points, symlinks, > > and so on. > > Ah. Well, let me register my (preliminary, rebuttable) opposition to that > second strategy in advance to hopefully make it clear well before it > becomes an issue that there is no current project consensus to go that > route and we need an actual design discussion (hopefully this time with > considerably more attention paid to details) before starting down that > path, if we do. > > (Now is not the time for that discussion; please don't try to convince me > that I'm wrong at the moment. I'm only asking that people remember that > this is not something we have all agreed upon.) No need to worry, as I mentioned there are two camps, as it's clear and obvious that there is no consensus one way or the other. There's loads more to do that is more useful and more urgent before it even gets down to this, as far as I'm concerned. Kind regards, Luca Boccassi
[toc] | [prev] | [next] | [standalone]
| From | HW42 <hw42@ipsumj.de> |
|---|---|
| Date | 2023-06-09 22:30 +0200 |
| Subject | Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) |
| Message-ID | <GEQU9-eNX0-1@gated-at.bofh.it> |
| In reply to | #108161 |
[Multipart message — attachments visible in raw view] — view raw
Helmut Grohne: > Hi Johannes, > > On Fri, Jun 09, 2023 at 05:47:56PM +0200, Johannes Schauer Marin Rodrigues wrote: >> if I understand that plan correctly, the usrmerge-support package >> setting up diversions is only necessary because you want to avoid >> having to do the move to /usr of *all* affected packages in the >> essential set in a single dinstall? Is that correct? > > This is not correct. In bookworm -> trixie upgrade scenario, we intend > to move all the files from / to /usr. Now we look into how this > happens focus on one particular symlink, without loss of generality > choose /bin. Since /bin is no longer in the dpkg database at the end > of the upgrade, some package must be the last one to contain /bin. > When upgrading (or removing that package), dpkg will attempt to remove > /bin (which in its opinion is an empty directory and the last consumer > is releasing it). However, since dpkg has no clue about file types, it > doesn't actually know that this is a directory and takes care of the > /bin -> /usr/bin symlink using unlink(). And this is where /bin > vanishes. Oops. > > So the idea here is to add a protective diversion for /bin such that > removing /bin instead removes some path we don't care about. [...] Did you consider just having one package keep one dummy file in /bin? While this isn't elegant it sounds much less complex than diversions and tricky pre-depend loops, etc. I might be very well missing something here (for example maybe it's really essential that no files remain in /bin, even not a dummy file). But in the other branch of this thread you welcomed "dumb" questions, so here you go ;]
[toc] | [prev] | [next] | [standalone]
| From | Helmut Grohne <helmut@subdivi.de> |
|---|---|
| Date | 2023-06-10 07:40 +0200 |
| Subject | Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg) |
| Message-ID | <GEZuq-eTpI-7@gated-at.bofh.it> |
| In reply to | #108167 |
Hi,
On Fri, Jun 09, 2023 at 09:57:21PM +0200, HW42 wrote:
> Did you consider just having one package keep one dummy file in /bin?
> While this isn't elegant it sounds much less complex than diversions and
> tricky pre-depend loops, etc.
The dummy file is not necessary. Debian packages can ship empty
directories. Having any package ship /bin (empty or not) is fully
sufficient to prevent dpkg from removing it.
> I might be very well missing something here (for example maybe it's
> really essential that no files remain in /bin, even not a dummy file).
> But in the other branch of this thread you welcomed "dumb" questions, so
> here you go ;]
Yeah, I consider the property that nothing ships anything in aliased
locations an important one. So let us go down for the consequences of
not doing that.
So some package will keep shipping /bin. It does't really matter which,
but clearly this package must be part of the essential set (otherwise
you could remove it and with it /bin would be deleted). This is cool for
upgrades, but less so for bootstrapping tools.
One of the approaches to making bootstrapping work was adding the
symlinks to some data.tar. That has been category 2 from my earlier
mail. We definitely cannot add /bin as a directory to one package and
/bin as a symlink to another (unless using diversions), because the
resulting behaviour is dependent on the unpack order when used with
dpkg. Also any bootstrap tool that unpacks with tar -k (such as
debootstrap) requires changes to support this. So this pretty much
precludes completing the transition in a way that just unpacking all
data.tar of essential packages gives you a working chroot. In effect,
this requires a proposal to change the bootstrap protocol (category 4)
in order to make sense.
There is a loop hole that I ignored here. While /bin cannot be both a
directory and a symlink at the same time, we can upgrade it. So if we
somehow managed to get one and only one package to contain /bin as a
directory, we could upgrade that to a symlink. Unfortunately, any
external package that still ships stuff in /bin breaks this. In effect,
any addon repository or old package can break your system.
The other way of seeing us keep /bin as a directory is to not
canonicalize (i.e. category 1). Then we'd simply keep (wlog) /bin/sh in
/bin and not move it to /usr.
Can you elaborate in what way you see protective diversions as adding
complexity? It can be as simple as:
dpkg-divert --add /bin --divert someplacewedontcare --package base-files --no-rename
We'd add this to one package and everyone else can issue Pre-Depends.
The benefit we gain from keeping /bin is not clear to me (beyond
avoiding a diversion). At this time, it seems to me that doing that
either requires changing all bootstrapping tools (in yet unspecified
ways) or never canonicalizing all paths (according to the dpkg
database).
Now I'm wondering what I am missing here.
Helmut
[toc] | [prev] | [next] | [standalone]
| From | Sven Joachim <svenjoac@gmx.de> |
|---|---|
| Date | 2023-06-10 08:40 +0200 |
| Subject | Re: booststrapping /usr-merged systems |
| Message-ID | <GF0qt-eTYE-1@gated-at.bofh.it> |
| In reply to | #108170 |
Am 10.06.2023 um 07:35 schrieb Helmut Grohne:
> One of the approaches to making bootstrapping work was adding the
> symlinks to some data.tar. That has been category 2 from my earlier
> mail. We definitely cannot add /bin as a directory to one package and
> /bin as a symlink to another (unless using diversions), because the
> resulting behaviour is dependent on the unpack order when used with
> dpkg. Also any bootstrap tool that unpacks with tar -k (such as
> debootstrap) requires changes to support this. So this pretty much
> precludes completing the transition in a way that just unpacking all
> data.tar of essential packages gives you a working chroot. In effect,
> this requires a proposal to change the bootstrap protocol (category 4)
> in order to make sense.
>
> There is a loop hole that I ignored here. While /bin cannot be both a
> directory and a symlink at the same time, we can upgrade it. So if we
> somehow managed to get one and only one package to contain /bin as a
> directory, we could upgrade that to a symlink.
I think the goal should be to get to this state eventually.
> 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?
Cheers,
Sven
[toc] | [prev] | [next] | [standalone]
| From | Sven Joachim <svenjoac@gmx.de> |
|---|---|
| Date | 2023-06-10 09:00 +0200 |
| Subject | Re: booststrapping /usr-merged systems |
| Message-ID | <GF0JP-eU59-1@gated-at.bofh.it> |
| In reply to | #108171 |
On 2023-06-10 08:35 +0200, Sven Joachim wrote:
> Am 10.06.2023 um 07:35 schrieb Helmut Grohne:
>
>> One of the approaches to making bootstrapping work was adding the
>> symlinks to some data.tar. That has been category 2 from my earlier
>> mail. We definitely cannot add /bin as a directory to one package and
>> /bin as a symlink to another (unless using diversions), because the
>> resulting behaviour is dependent on the unpack order when used with
>> dpkg. Also any bootstrap tool that unpacks with tar -k (such as
>> debootstrap) requires changes to support this. So this pretty much
>> precludes completing the transition in a way that just unpacking all
>> data.tar of essential packages gives you a working chroot. In effect,
>> this requires a proposal to change the bootstrap protocol (category 4)
>> in order to make sense.
>>
>> There is a loop hole that I ignored here. While /bin cannot be both a
>> directory and a symlink at the same time, we can upgrade it. So if we
>> somehow managed to get one and only one package to contain /bin as a
>> directory, we could upgrade that to a symlink.
>
> I think the goal should be to get to this state eventually.
>
>> 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?
Thinking about it once more, I understand that unpacking old or external
packages during the bootstrap phase could break it if those are unpacked
before the package shipping the /bin symlink, and this is what you meant.
Cheers,
Sven
[toc] | [prev] | [next] | [standalone]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | linux.debian.devel
csiph-web