Hi, Helmut. I'm very sorry for responding to an 8-months old letter,
but I think my message is important.
Helmut Grohne:
> * mmdebstrap operates in two phases. It first unpacks and configures a
> rather minimal set of packages and then proceeds to adding packages
> passed to --include in a sec
On Sun, 11 Jun 2023 at 22:17, Timo Röhling wrote:
>
> * Luca Boccassi [2023-06-10 19:54]:
> >I would caution to avoid interpreting clarifying questions being asked
> >as dissent. It's good to ask questions and clarify details about
> >corner cases, but I wouldn't automatically write them down as
* Luca Boccassi [2023-06-10 19:54]:
I would caution to avoid interpreting clarifying questions being asked
as dissent. It's good to ask questions and clarify details about
corner cases, but I wouldn't automatically write them down as
disagreement. At least that's my reading of recent parts of th
On Sun, 11 Jun 2023 at 19:07, Russ Allbery wrote:
>
> Luca Boccassi writes:
> > On Sun, 11 Jun 2023 at 18:06, Russ Allbery 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 pa
Luca Boccassi writes:
> On Sun, 11 Jun 2023 at 18:06, Russ Allbery 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
>> wou
On Sun, 11 Jun 2023 at 18:06, Russ Allbery 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
Helmut Grohne 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
On Sun, 11 Jun 2023, 14:32 Jeroen Dekkers, 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 dif
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 b
On Sat, 10 Jun 2023 at 09:40, Helmut Grohne wrote:
> My takeaway here is that while I see the protective diversion as the
> "obviously superior solution", this clearly is not consensus at this
> time. It also means that when rewriting DEP 17, I need to spend quite a
> bit of text on rationale. Tha
On 2023-06-10 10:39 +0200, Helmut Grohne wrote:
> Hi Sven,
>
> On Sat, Jun 10, 2023 at 08:35:44AM +0200, Sven Joachim wrote:
>> > Unfortunately, any
>> > external package that still ships stuff in /bin breaks this. In effect,
>> > any addon repository or old package can break your system.
>>
>> Yo
Hi Sven,
On Sat, Jun 10, 2023 at 08:35:44AM +0200, Sven Joachim wrote:
> > Unfortunately, any
> > external package that still ships stuff in /bin breaks this. In effect,
> > any addon repository or old package can break your system.
>
> You lost me. We have converted /bin to a symlink already, h
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
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 usi
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 em
Hi,
On 10.06.23 00:41, Steve McIntyre wrote:
What exactly do you mean here? You know that even a statically linked
executable needs an interpreter defined in the ELF header?
/sbin/ldconfig has no PT_INTERP segment.
If you use libdl, you need to be loaded through ld.so, and since PAM
uses li
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*
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?
I know I haven't thought about this as much as others, so I might be
naively missing something here.
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
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).
> > Ho
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 direc
Steve McIntyre writes:
> Raphaël Hertzog wrote:
>>
>>In the same spirit, I'd like to throw an idea... could we decide that
>>base-files is the first package to be configured as part of the bootstrap
>>protocol and change base-files maintainer's scripts into statically linked
>>executables so that
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 t
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 b
Raphaël Hertzog wrote:
>
>In the same spirit, I'd like to throw an idea... could we decide that
>base-files is the first package to be configured as part of the bootstrap
>protocol and change base-files maintainer's scripts into statically linked
>executables so that they can work even if we don't
Quoting Marco d'Itri (2023-06-09 09:41:43)
> On Jun 08, Raphael Hertzog 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,
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 lin
On Jun 09, Bjørn Mork 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 becau
Marco d'Itri 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
f
On Fri, 9 Jun 2023 at 10:53, Raphael Hertzog wrote:
>
> On Fri, 09 Jun 2023, Marco d'Itri wrote:
> > On Jun 08, 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
>
On Fri, 09 Jun 2023, Marco d'Itri wrote:
> On Jun 08, 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 stati
On Jun 08, 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 ev
On Thu, 8 Jun 2023 at 09:46, Raphael Hertzog wrote:
>
> Hi,
>
> On Wed, 17 May 2023, Helmut Grohne wrote:
> > For completeness sake, there is one more entry in category 3: We can run
> > the dynamic loader from its canonical location explicitly, so we'd
> > modify maintainer scripts to start with:
Hi,
On Wed, 17 May 2023, Helmut Grohne wrote:
> For completeness sake, there is one more entry in category 3: We can run
> the dynamic loader from its canonical location explicitly, so we'd
> modify maintainer scripts to start with:
>
> #!/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /usr/bi
On Fri, 19 May 2023 at 01:30, Simon Richter wrote:
>
> Hi,
>
> On 5/18/23 18:08, Luca Boccassi wrote:
>
> >> Without it, leaving them in place makes no difference for usrmerged
> >> systems, and allows derived distributions that don't need usrmerge to
> >> continue using our packages.
>
> > Not qu
Hi,
On 5/18/23 18:08, Luca Boccassi wrote:
Without it, leaving them in place makes no difference for usrmerged
systems, and allows derived distributions that don't need usrmerge to
continue using our packages.
Not quite. Having packages only ship files under /usr (and possibly
/etc) is very
On Thu, 18 May 2023 at 07:39, Simon Richter wrote:
>
> Hi,
>
> On 5/18/23 02:15, Sam Hartman wrote:
>
> > Helmut> I think at this point, we have quite universal consensus
> > Helmut> about the goal of moving files to their canonical location
> > Helmut> (i.e. from / to /usr) as a so
Hi,
On 5/18/23 02:15, Sam Hartman wrote:
Helmut> I think at this point, we have quite universal consensus
Helmut> about the goal of moving files to their canonical location
Helmut> (i.e. from / to /usr) as a solution to the aliasing problems
Helmut> while we do not have cons
> "Helmut" == Helmut Grohne writes:
Helmut> Moving on to category 4 feels rather obvious, especially
Helmut> because work has been done there in debootstrap. The
Helmut> approach in debootstrap however is one that I see as a dead
Helmut> end, because it causes us to maintain t
> "Helmut" == Helmut Grohne writes:
Helmut> I think at this point, we have quite universal consensus
Helmut> about the goal of moving files to their canonical location
Helmut> (i.e. from / to /usr) as a solution to the aliasing problems
Helmut> while we do not have consensus o
On Wed, 17 May 2023 at 10:31, Helmut Grohne wrote:
>
> Hi,
>
> This bootstrap aspect got me and I discussed this with a number of
> people and did some research.
>
> On Sun, May 07, 2023 at 12:51:21PM +0100, Luca Boccassi wrote:
> > I don't think this is true? At least not in the broader sense: if
On May 17, Helmut Grohne wrote:
> Given the feedback, I am convinced that changing PT_INTERP is a stupid
> idea regardless of whether it is technically feasible. There must be a
> better way. Let's step back a bit.
Me too, I was never persuaded.
> 4. Change the bootstrap protocol. In essence, t
At 2023-05-17T11:30:36+0200, Helmut Grohne wrote:
> This bootstrap aspect got me and I discussed this with a number of
> people and did some research.
I'd like to nominate you for a Russ Allbery Award for the most useful
post to the thread. Your attention to concrete, empirical details,
arising n
43 matches
Mail list logo
