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
Hi!
On Wed, 2023-06-21 at 23:24:53 +0900, Simon Richter wrote:
> On 6/21/23 20:33, Guillem Jover wrote:
> > I don't think we disagree (?), I probably didn't express myself clearly.
> > The fact that no package ships those symlinks *is* and *has* been a
> > problem, and what I've been saying all al
Hi,
On 6/21/23 20:33, Guillem Jover wrote:
I don't think we disagree (?), I probably didn't express myself clearly.
The fact that no package ships those symlinks *is* and *has* been a
problem, and what I've been saying all along, this will be the only
correct way to let dpkg know whether there
Hi!
On Sat, 2023-04-22 at 10:27:26 +0200, Helmut Grohne wrote:
> On Sat, Apr 08, 2023 at 04:35:25AM +0200, Guillem Jover wrote:
> > Let's also get back to the very basics. dpkg manages objects shipped
> > in binary packages, on the filesystem. It assumes this managing role in
> > exclusivity, it w
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
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 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
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 Sun, 2023-05-21 at 16:25 +0200, Helmut Grohne wrote:
> On a process level, I think I miss attempts to resolve this with the
> dpkg maintainer in a constructive way.
The patch was already suggested to the dpkg maintainer and rejected.
> Does anyone mind just closing the bug?
Yes, I do.
Please
Hi Ansgar,
I'm speaking with a CTTE hat here, but not representing CTTE consensus.
On Wed, May 10, 2023 at 11:47:42PM +0200, Ansgar wrote:
> Dear ctte, please consider overruling the dpkg maintainer to include
> the patch from #994388[1].
I think we need to reject this request on multiple levels
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
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 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 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
> "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 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 (
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
Hi Simon,
On Fri, Apr 28, 2023 at 02:07:33PM +0200, Simon Richter wrote:
> Transforming existing diversions: yes, if you can find out about them
> without looking at dpkg internal files. It may very well be necessary to
> update the file format on one of these, and if that would cause your
> scrip
Hi,
On Thu, Apr 27, 2023 at 12:34:06AM +0200, Helmut Grohne wrote:
> Ok, let's move on. I've proposed diversions as a cure, but in reality
> diversions are a problem themselves. Consider that
> cryptsetup-nuke-password diverts /lib/cryptsetup/askpass, which is
> usually owned by cryptsetup. If cr
* Luca Boccassi [2023-04-28 10:12]:
Which part of config-package-dev causes a conflict here? Is it
something that can be fixed? Given it's declarative, an upload + rdeps
rebuild should be all that's needed, assuming we know what the issue
is and how to fix it. As far as I can remember, it's a bu
On Fri, 28 Apr 2023 at 09:09, Helmut Grohne wrote:
>
> On Thu, Apr 27, 2023 at 12:34:06AM +0200, Helmut Grohne wrote:
> > Ok, let's move on. I've proposed diversions as a cure, but in reality
> > diversions are a problem themselves. Consider that
> > cryptsetup-nuke-password diverts /lib/cryptsetu
On Thu, Apr 27, 2023 at 12:34:06AM +0200, Helmut Grohne wrote:
> Ok, let's move on. I've proposed diversions as a cure, but in reality
> diversions are a problem themselves. Consider that
> cryptsetup-nuke-password diverts /lib/cryptsetup/askpass, which is
> usually owned by cryptsetup. If cryptset
Hi Simon,
On Sat, Apr 22, 2023 at 11:41:29AM +0100, Simon McVittie wrote:
> You might reasonably say that "the maintainer of bar didn't add the
> correct Breaks/Replaces on foo" is a RC bug in bar - and it is! - but
> judging by the number of "missing Breaks/Replaces" bug reports that have
> to be
Hi,
On Thu, Apr 27, 2023 at 12:34:06AM +0200, Helmut Grohne wrote:
> At some point the question becomes: Do we want that complexity inside
> dpkg (aka DEP 17 or some variant of it) or outside of dpkg (i.e. what
> we're talking about here). It seems clear at this time, that complexity
> is unavoid
On Wed, Apr 26, 2023 at 07:11:10AM -0600, Sam Hartman wrote:
> > "Simon" == Simon McVittie writes:
>
> Simon> You might reasonably say that "the maintainer of bar didn't
> Simon> add the correct Breaks/Replaces on foo" is a RC bug in bar -
> Simon> and it is! - but judging by the
On Tue, Apr 25, 2023 at 09:07:28PM +0200, Helmut Grohne wrote:
> In sincerely hope that this fixed-up plan doesn't have any serious
> issues. If you find any please tell.
Thanks for the praise, but problems I found and I'm pretty sure this is
only the tip of the iceberg.
So for one thing, let us
On 2023-04-26 10:34 +0100, Luca Boccassi wrote:
> On Wed, 26 Apr 2023 at 10:11, Simon Richter wrote:
>>
>> What I'm mostly concerned about (read: have not verified either way)
>> with /lib/ld.so and /bin/sh is what happens when dpkg learns of /bin and
>> /lib as symlinks -- because right now, the
Le mar. 25 avr. 2023 à 19:08, Helmut Grohne a écrit :
>
> Hi Luca,
>
> On Sat, Apr 22, 2023 at 01:06:18PM +0100, Luca Boccassi wrote:
> > On Sat, 22 Apr 2023 at 11:50, Helmut Grohne wrote:
> > > On Fri, Apr 21, 2023 at 03:29:33PM +0100, Luca Boccassi wrote:
> > > > After Bookworm ships I plan to
On Tue, 25 Apr 2023, Luca Boccassi wrote:
> Brilliant! Would never have thought of using divert like that.
+1 Nice trick.
> So, what work would need to happen to make this reality? Do we need
> tooling/scripts/build changes to support the divert scheme, or is it
> "simply" a matter of documenting
> "Simon" == Simon McVittie writes:
Simon> You might reasonably say that "the maintainer of bar didn't
Simon> add the correct Breaks/Replaces on foo" is a RC bug in bar -
Simon> and it is! - but judging by the number of "missing
Simon> Breaks/Replaces" bug reports that have to
On Wed, 26 Apr 2023 at 10:11, Simon Richter wrote:
>
> Hi,
>
> On Tue, Apr 25, 2023 at 09:07:28PM +0200, Helmut Grohne wrote:
>
> > This and /bin/sh is the kind of files I'd consider important. And then
> > upon thinking further it became more and more difficult for me to make
> > sense of the obj
1 - 100 of 123 matches
Mail list logo
