> "Guillem" == Guillem Jover writes:
Guillem> At least the dpkg behavior seems entirely
Guillem> correct to me and required for safe upgrades (
Can you help me understand the sentence above?
Where is the case where this behavior is needed for safe upgrades?
(I am asking out of cu
> "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
> "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
> "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
> "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
> "Helmut" == Helmut Grohne writes:
Helmut> Indeed, and I do agree that 4c is such a clear statement. I
Helmut> would like to see a stronger statement here, but Sam et
Helmut> al. tried to gain consensus on that and there wasn't. So the
Helmut> CTTE advice probably shouldn't ov
I'm ignoring the case where capabilities are dropped in my analysis.
I've long valued that Debian does not mark file paths as readonly and
would not support this change.
I've worked on other Unix distributions that did this, and I found that
it decreased the quality of life of the sysadmin enoug
I'm concerned about a leading . at least for:
* the debian/tmp replacement
* the replacement for the package install directories under debian.
I think that maintaining those directories such that ls shows them will
be more friendly for new maintainers.
So I'd prefer something like debian/build ra
> "Bastian" == Bastian Blank writes:
>> I don't think this proposal is sufficiently well developed where
>> you're going to get much good feedback on debian-devel.
Bastian> What would be the correct location for it?
I'm fairly frustrated that you snipped the key part of my mail
Hi.
My initial reaction is that this is additional complexity in a direction
that we don't need.
Like Russ, I generally assume that VCS-like things are the future.
I understand there is complexity there.
But I don't understand why this proposed format would be a step forward
in a world where we
> "Michael" == Michael Stone writes:
Michael> On Fri, May 10, 2019 at 05:18:18AM +0200, Guillem Jover wrote:
>> be updated anyway to support any new format. It also destroys
>> some of the nice properties of the 2.x format, namely:
>>
>> - Not requiring special tools to b
12 matches
Mail list logo
