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, 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
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
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 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 26/05/2023 09:24, Luca Boccassi wrote:
On Fri, 26 May 2023 at 08:39, Matthew Vernon wrote:
Consider: it is consistent to believe that it would have been better for
dpkg not to have had that warning added (quite some time ago now), but
that by now most derivatives that care will likely have
On Fri, 26 May 2023 at 08:39, Matthew Vernon wrote:
>
> Hi,
>
> On 26/05/2023 07:03, Ansgar wrote:
> > On Wed, 2023-05-10 at 14:36 -0700, Russ Allbery wrote:
> >> Ansgar writes:
> >>> Debian going out of its way to tell derivative users to switch back from
> >>> merged-/usr to split-/usr is the *
On Fri, 2023-05-26 at 08:39 +0100, Matthew Vernon wrote:
> > So let me summarize Debian's "official" position as I understand it: we
> > do *NOT* care how dpkg's recommendations will break derivative
> > installations at all; if systems become unbootable, cause data loss,
> > ... now or in the futu
Hi,
On 26/05/2023 07:03, Ansgar wrote:
On Wed, 2023-05-10 at 14:36 -0700, Russ Allbery wrote:
Ansgar writes:
Debian going out of its way to tell derivative users to switch back from
merged-/usr to split-/usr is the *opposite* of trying to make things as
smooth for them as possible.
Yes, I a
Hi Russ,
On Wed, 2023-05-10 at 14:36 -0700, Russ Allbery wrote:
> Ansgar writes:
> > Debian going out of its way to tell derivative users to switch back from
> > merged-/usr to split-/usr is the *opposite* of trying to make things as
> > smooth for them as possible.
>
> Yes, I agree with that pa
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
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 you
> compile something on Debian, it will obviously get linked a
On Sat, 13 May 2023 at 14:59, RL wrote:
>
> Luca Boccassi writes:
>
> > I think documentation is fundamental for dealing with local
> > changes. When I say that I don't think we should worry about strange
> > local-only changes I mean exactly as you said, that I don't think we
> > should start sh
Luca Boccassi writes:
> I think documentation is fundamental for dealing with local
> changes. When I say that I don't think we should worry about strange
> local-only changes I mean exactly as you said, that I don't think we
> should start shipping complicated code that tries to deal with people
Package: tech-ctte
X-Debbugs-Cc: Russ Allbery , Sean Whitton
, Helmut Grohne , Luca Boccassi
, debian-d...@lists.debian.org, debian-devel@lists.debian.org
On Wed, 2023-05-10 at 14:36 -0700, Russ Allbery wrote:
> Ansgar writes:
> > Debian going out of its way to tell derivative users to switch b
Ansgar writes:
> On Wed, 2023-05-10 at 13:50 -0700, Russ Allbery wrote:
>> Caring about them isn't the same thing as doing everything they want.
>> We can both try to make things as smooth for them as possible and still
>> make design decisions about Debian that they may disagree with or that
>>
Hi Russ,
On Wed, 2023-05-10 at 13:50 -0700, Russ Allbery wrote:
> Ansgar writes:
> > As far as I understand, we do explicitly *not* care about our
> > derivatives with regard to merged-/usr as some packages in Debian
> > recommend users to move *away* from merged-/usr to split-/usr on
> > derivat
Ansgar writes:
> So why do we allow changes that require listing all reverse dependencies
> in Breaks then? This is known to be wrong for all non- listed packages,
> e.g., all local/vendor/derivative-specific packages.
Because it's a balance; we don't want to stop making changes, and never
makin
On Wed, 2023-05-10 at 08:35 -0700, Sean Whitton wrote:
> On Sun 07 May 2023 at 11:14AM +02, Ansgar wrote:
> > Debian's dependency system requires to explicitly declare
> > Depends/Conflicts/Replaces/Breaks, but for obvious reasons we
> > cannot do
> > that for packages outside Debian's ecosystem.
>
Hello,
On Tue 09 May 2023 at 02:07AM +01, Luca Boccassi wrote:
> But again, I do think we need to try and define what it is that we
> want to support here. If we are serious about it, then we should
> codify it, and hold any future changes to the same standards, wherever
> they may come from. If
Hello,
On Sun 07 May 2023 at 11:14AM +02, Ansgar wrote:
> Debian's dependency system requires to explicitly declare
> Depends/Conflicts/Replaces/Breaks, but for obvious reasons we cannot do
> that for packages outside Debian's ecosystem.
>
> The same is true for diversions/alternatives/* or anyth
On Tue, 9 May 2023 at 05:12, Helmut Grohne wrote:
>
> Hi Luca,
>
> On Tue, May 09, 2023 at 01:56:53AM +0100, Luca Boccassi wrote:
> > On Mon, 8 May 2023 at 19:06, Sean Whitton wrote:
> > > It's designed to stop as-yet-unknown problems happening, too.
> >
> > Well, sure, but we've been at this for
Hi Luca,
On Tue, May 09, 2023 at 01:56:53AM +0100, Luca Boccassi wrote:
> On Mon, 8 May 2023 at 19:06, Sean Whitton wrote:
> > It's designed to stop as-yet-unknown problems happening, too.
>
> Well, sure, but we've been at this for years, any such problems should
> really be known by now. This i
On Mon, 8 May 2023 at 21:09, Russ Allbery wrote:
>
> Sam Hartman writes:
>
> > As someone who has been following this, I support the work Helmut and
> > Simon Richter have been doing.
>
> > I have more confidence in that view than the one Luca is proposing.
> > I also support Shawn's interpretati
On Mon, 8 May 2023 at 19:06, Sean Whitton wrote:
>
> Hello,
>
> On Sun 07 May 2023 at 12:03PM +01, Luca Boccassi wrote:
>
> > Sure, this is in the context of the ongoing discussion in the TC about
> > revising their side of the advice.
>
> I think it's highly unlikely that we revise it rather than
On Mon, 8 May 2023 at 09:58, Helmut Grohne wrote:
>
> On Mon, May 08, 2023 at 02:07:08AM +0100, Luca Boccassi wrote:
> > I can see we don't agree on this matter, of course, that is clear. And
> > I hope we can find common ground. But let me provocatively ask this
> > first: is the same rule going
Will get to the rest later tonight, two quick points:
On Mon, 8 May 2023 at 09:58, Helmut Grohne wrote:
> > But the more I think about it, the more I am convinced that the
> > default option working best for Debian is the one that matches the
> > project's choice of a filesystem layout. After all
Sam Hartman writes:
> As someone who has been following this, I support the work Helmut and
> Simon Richter have been doing.
> I have more confidence in that view than the one Luca is proposing.
> I also support Shawn's interpretation that being conservative here is
> good.
> I think even with
> "Helmut" == Helmut Grohne writes:
Helmut> Hi Luca,
Helmut> On Sun, May 07, 2023 at 12:51:21PM +0100, Luca Boccassi wrote:
>> The local/external aspect is already covered in Ansgar's reply
>> and subthread.
Helmut> I hope that we can at least agree that we don't have
Hello,
On Sun 07 May 2023 at 12:03PM +01, Luca Boccassi wrote:
> Sure, this is in the context of the ongoing discussion in the TC about
> revising their side of the advice.
I think it's highly unlikely that we revise it rather than just reissue
it, at the present time, because too many details a
Hi,
On 5/8/23 20:38, Luca Boccassi wrote:
[local diversions]
Sure, they are supported in the sense that they can be enabled, and
then you get to keep the pieces.
They are supported in the sense that someone actually added an explicit
flag for dpkg-divert for specifically this feature and do
On Mon, 8 May 2023 at 03:57, Simon Richter wrote:
>
> Hi,
>
> On 5/7/23 18:14, Ansgar wrote:
>
> > Is there any specific reason why specifically diversions are a problem
> > where "it might work" is not sufficient? That is, why should we divert
> > from the usual standard for dealing with packages
On Mon, May 08, 2023 at 02:07:08AM +0100, Luca Boccassi wrote:
> I can see we don't agree on this matter, of course, that is clear. And
> I hope we can find common ground. But let me provocatively ask this
> first: is the same rule going to be enforced for all other changes
> that happen in the pro
Hi,
On 5/7/23 18:14, Ansgar wrote:
Is there any specific reason why specifically diversions are a problem
where "it might work" is not sufficient? That is, why should we divert
from the usual standard for dealing with packages outside the Debian
ecosystem here?
Locally created diversions are
On Sun, 7 May 2023 at 22:10, Helmut Grohne wrote:
>
> Hi Luca,
>
> On Sun, May 07, 2023 at 12:51:21PM +0100, Luca Boccassi wrote:
> > The local/external aspect is already covered in Ansgar's reply and
> > subthread.
>
> I hope that we can at least agree that we don't have consensus on this
> view
Hi Luca,
On Sun, May 07, 2023 at 12:51:21PM +0100, Luca Boccassi wrote:
> The local/external aspect is already covered in Ansgar's reply and subthread.
I hope that we can at least agree that we don't have consensus on this
view. And the more I think about it, the more it becomes clear to me
that
On Sun, 7 May 2023 at 12:51, Luca Boccassi wrote:
>
> On Sun, 7 May 2023 at 06:55, Helmut Grohne wrote:
> >
> > Hi Luca,
> >
> > On Sat, May 06, 2023 at 09:47:15PM +0100, Luca Boccassi wrote:
> > > Sure, there are some things that need special handling, as you have
> > > pointed out. What I meant
On Sun, 7 May 2023 at 06:55, Helmut Grohne wrote:
>
> Hi Luca,
>
> On Sat, May 06, 2023 at 09:47:15PM +0100, Luca Boccassi wrote:
> > Sure, there are some things that need special handling, as you have
> > pointed out. What I meant is that I don't think we need special
> > handling for _all_ affec
On Sun, 7 May 2023 at 00:44, Sean Whitton wrote:
>
> Hello,
>
> On Sat 06 May 2023 at 09:47PM +01, Luca Boccassi wrote:
>
> > On Sat, 6 May 2023 at 19:51, Helmut Grohne wrote:
> >>
> >> > - the moratorium on moving files from bin/ sbin/ lib/ _and_ to other
> >> > packages at the same time is main
On Sun, 7 May 2023 at 10:14, Ansgar wrote:
>
> Hi,
>
> On Sun, 2023-05-07 at 07:50 +0200, Helmut Grohne wrote:
> > But then, you only capture diversions inside Debian's ecosystem
>
> It's unreasonable to support stuff outside Debian's ecosystem: even
> basic dependency relations do not work for th
Hi,
On Sun, 2023-05-07 at 07:50 +0200, Helmut Grohne wrote:
> But then, you only capture diversions inside Debian's ecosystem
It's unreasonable to support stuff outside Debian's ecosystem: even
basic dependency relations do not work for this.
Debian's dependency system requires to explicitly dec
Hi,
On Sun, 2023-05-07 at 07:50 +0200, Helmut Grohne wrote:
> But then, you only capture diversions inside Debian's ecosystem and miss
> out on other kinds of diversions such as local diversions. We currently
> support imposing local diversions on pretty much arbitrary files
> including unit files
Hi Luca,
On Sat, May 06, 2023 at 09:47:15PM +0100, Luca Boccassi wrote:
> Sure, there are some things that need special handling, as you have
> pointed out. What I meant is that I don't think we need special
> handling for _all_ affected packages. AFAIK nothing is using
> diversions for unit files
Hello,
On Sat 06 May 2023 at 09:47PM +01, Luca Boccassi wrote:
> On Sat, 6 May 2023 at 19:51, Helmut Grohne wrote:
>>
>> > - the moratorium on moving files from bin/ sbin/ lib/ _and_ to other
>> > packages at the same time is maintained from bookworm till trixie, and
>> > will lifted after trixi
On Sat, 6 May 2023 at 19:51, Helmut Grohne wrote:
>
> Hi Luca,
>
> I fear you are still missing too many relevant details. What sounds like
> a simple plan is severely broken if carried out in this simple form. It
> disappoints me that you continue to present it as this simple given the
> earlier
On Sat, 6 May 2023 at 19:51, Helmut Grohne wrote:
>
> Hi Luca,
>
> On Sat, May 06, 2023 at 04:52:30PM +0100, Luca Boccassi wrote:
> > To have a working system you need several more steps that are
> > performed by the instantiator/image builder, such as providing working
> > and populated proc/sys/
Hi Luca,
On Sat, May 06, 2023 at 04:52:30PM +0100, Luca Boccassi wrote:
> To have a working system you need several more steps that are
> performed by the instantiator/image builder, such as providing working
> and populated proc/sys/dev, writable tmp/var, possibly etc. And it
> needs to be instan
On Sat, 6 May 2023 at 16:11, Simon Richter wrote:
>
> Hi,
>
> On 06.05.23 21:28, Luca Boccassi wrote:
>
> [shipping usrmerge symlinks in packages]
>
> > In the far future I'd like for these details to be owned by image
> > builders/launchers/setup processes rather than a package, but this can
> >
Hi,
On 06.05.23 21:28, Luca Boccassi wrote:
[shipping usrmerge symlinks in packages]
In the far future I'd like for these details to be owned by image
builders/launchers/setup processes rather than a package, but this can
be discussed separately and independently, no need to be tied to this
ef
On Sat, 6 May 2023 at 11:00, Simon McVittie wrote:
>
> On Fri, 05 May 2023 at 23:11:54 +0100, Luca Boccassi wrote:
> > In practice, I suspect that out of ~2000 packages shipping bin/ sbin/
> > lib*/, only a small fraction would end up needing to further move
> > files out to other packages
>
> I t
On Sat, 6 May 2023 at 06:21, Simon Richter wrote:
>
> Hi,
>
> On 06.05.23 07:11, Luca Boccassi wrote:
>
> > - every package is forcefully canonicalized as soon as trixie is open
> > for business
>
> You will also need to ship at least
>
> - /lib -> usr/lib (on 32 bit)
> - /lib64 -> usr/lib64 (
On Fri, 05 May 2023 at 23:11:54 +0100, Luca Boccassi wrote:
> In practice, I suspect that out of ~2000 packages shipping bin/ sbin/
> lib*/, only a small fraction would end up needing to further move
> files out to other packages
I think the most common case for this is likely to be systemd system
Hi,
On 06.05.23 07:11, Luca Boccassi wrote:
- every package is forcefully canonicalized as soon as trixie is open
for business
You will also need to ship at least
- /lib -> usr/lib (on 32 bit)
- /lib64 -> usr/lib64 (on 64 bit)
as a symlink either in the libc-bin package or any other Essen
On Fri, 5 May 2023 at 17:38, Andreas Metzler wrote:
>
> On 2023-05-05 Simon Richter wrote:
> [...]
> > My proposal would be to put the onus on the client registering the
> > diversion:
> [...]
> > - packages are encouraged to register both diversions
>
> Hello,
>
> That seems to be a rather ugly
On 2023-05-05 Simon Richter wrote:
[...]
> My proposal would be to put the onus on the client registering the
> diversion:
[...]
> - packages are encouraged to register both diversions
Hello,
That seems to be a rather ugly user interface, ("There is dpkg-divert on
Debian, but because the usrmer
Hi,
On 05.05.23 18:36, Timo Röhling wrote:
- it is not an error to register a diversion for an alias of an
existing diversion, provided the package and target matches, this is a
no-op
- it is not an error to unregister a diversion for an alias of a path
that has been unregistered previously,
Hi,
* Simon Richter [2023-05-05 17:59]:
- it is not an error to register a diversion for an alias of an
existing diversion, provided the package and target matches, this is a
no-op
- it is not an error to unregister a diversion for an alias of a path
that has been unregistered previously, tha
Hi,
On 04.05.23 20:26, Helmut Grohne wrote:
From my point of view, the ultimate goal here should be moving all files
to their canonical location and thereby make aliasing effects
irrelevant. Do you confirm?
Yes, that would solve the problem for the current transition without any
changes in
Hi Simon,
On Thu, May 04, 2023 at 03:37:49AM +0900, Simon Richter wrote:
> For aliasing support in dpkg, that means we need a safe policy of dealing
> with diversions that conflict through aliasing that isn't "reject with
> error", because the magic dpkg-divert would always generate conflicts.
I
Hi,
On 03.05.23 19:19, Helmut Grohne wrote:
What still applies here is that we can have usr-is-merged divert
/usr/bin/dpkg-divert and have it automatically duplicate any possibly
aliased diversion and then the diverter may Pre-Depends: usr-is-merged
(>=...) to have its diversions duplicated. Of
On Wed, May 03, 2023 at 10:31:14AM +0200, Raphael Hertzog wrote:
> On Tue, 02 May 2023, Helmut Grohne wrote:
> > I think there is a caveat (whose severity I am unsure about): In order
> > to rely on this (and on DEP 17), we will likely have versioned
> > Pre-Depends on dpkg. Can we reasonably rule
Hi Raphaël,
On Wed, May 03, 2023 at 10:31:14AM +0200, Raphael Hertzog wrote:
> I don't know APT well enough to answer that question but from my point of
> view it's perfectly acceptable to document in the release notes that you
> need to upgrade dpkg first.
Yes, this issue seems vaguely solvable
Hello,
On Tue, 02 May 2023, Helmut Grohne wrote:
> I think there is a caveat (whose severity I am unsure about): In order
> to rely on this (and on DEP 17), we will likely have versioned
> Pre-Depends on dpkg. Can we reasonably rule out the case where and old
> dpkg is running, unpacking a fixed d
> "Helmut" == Helmut Grohne writes:
Helmut> Luca Boccassi kindly pointed me at config-package-dev
Helmut> though. This is a tool for generating local packages and it
Helmut> also employs dpkg-divert. There is a significant risk of
Helmut> breaking this use case. If we were to
On Tue, May 02, 2023 at 02:09:32PM +0200, Helmut Grohne wrote:
> This is problems we know about now, but it likely is not an exhaustive
> list. This list was mostly guided by Guillem's intuition of what could
> break at https://wiki.debian.org/Teams/Dpkg/MergedUsr and I have to say
> that his intui
On Tue, May 02, 2023 at 02:09:32PM +0200, Helmut Grohne wrote:
> I noticed that the number of packages shipping non-canonical files is
> relatively small. It's less than 2000 binary packages in unstable and
> their total size is about 2GB. So I looked into binary-patching them and
> attach the resu
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
> automatic
Hi Raphaël,
On Tue, May 02, 2023 at 12:30:21PM +0200, Raphael Hertzog wrote:
> 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
>
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 loc
Hi Marvin,
On Sat, Apr 29, 2023 at 02:08:37PM -0400, Marvin Renich wrote:
> My understanding from following this thread (and others) is that dpkg
> has a bug that can easily be triggered by a sysadmin replacing a
> directory with a symlink (and some other necessary conditions that don't
> happen v
Hi,
On 30.04.23 03:08, Marvin Renich wrote:
My understanding from following this thread (and others) is that dpkg
has a bug that can easily be triggered by a sysadmin replacing a
directory with a symlink (and some other necessary conditions that don't
happen very often), which is explicitly all
* Helmut Grohne [230428 09:50]:
> I think we have a misunderstanding here. As far as I understand it, the
> core idea of Luca's approach is that we move all files to their
> canonical locations and then - when nothing is left in directories such
> as /bin or /lib - there is no aliasing anymore, wh
On Fri, 28 Apr 2023 at 10:12, Luca Boccassi wrote:
>
> On Fri, 28 Apr 2023 at 09:09, Helmut Grohne wrote:
> > So yeah, with the exception of dash, this looks fairly good. Let me also
> > dive into dash. Unlike the majority of diverters, it diverts in postinst
> > rather than preinst to allow cont
Please excuse the volume of mails I am producing at this time, but I
still think this adds to the discussion.
On Thu, Apr 27, 2023 at 12:34:06AM +0200, Helmut Grohne wrote:
> I have a bad feeling about this. I think some dpkg maintainer warned us
> that diversions would break. Let's peek at his li
Helmut Grohne writes:
> On Thu, Apr 27, 2023 at 10:58:46AM +0200, Marc Haber wrote:
>> My gut feeling is that we are wasting prescious time of numerous
>> skilled Debian Developers to find ugly workarounds to something that
>> should be done in dpkg, but isnt being done because one dpkg maintaine
On Fri, 28 Apr 2023 at 17:52, Jochen Sprickerhof wrote:
>
> Hi James,
>
> * James Addison [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 c
Hi James,
* James Addison [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'
1 - 100 of 138 matches
Mail list logo
