Hi Helmut,
On 2023-10-07 12:47, Helmut Grohne wrote:
> The CTTE has ruled that from trixie onward, maintainers may rely on
> systems being merged-/usr. This includes the build environment.
> ---
> modules/schroot/files/setup-dchroot | 12 +++-
> 1 file changed, 11 i
On Sat, 07 Oct 2023 at 12:47:04 +0200, Helmut Grohne wrote:
> would you consider applying the patch to dsa-puppet.git? It is meant to
> convert trixie and newer chroots to merged-/usr.
This partially reverts my earlier change
<https://salsa.debian.org/dsa-team/mirror/dsa-puppet
The CTTE has ruled that from trixie onward, maintainers may rely on
systems being merged-/usr. This includes the build environment.
---
modules/schroot/files/setup-dchroot | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
Hi DSA,
would you consider applying the patch to dsa
s already a symlink
> on
> non-merged-/usr systems, pointing to
> /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2, why would
> it be an issue to have /lib64/ld-linux-x86-64.so.2 point to
> /usr/lib64/ld-linux-x86-64.so.2?
I don't think it would be, and I don't think anyone e
Luca Boccassi writes:
> On Wed, 17 May 2023 at 01:05, Russ Allbery wrote:
>> I do think the industry is moving away (well, has already moved away)
>> from Linux Standards Base pre-compiled C binaries without wrappers like
>> snap or flatpak, although there are some very notable exceptions, such
On Wed, 17 May 2023 at 01:05, Russ Allbery wrote:
>
> Luca Boccassi writes:
>
> > It does say something interesting. When we started, the assertion was
> > that packages not relying on the symlink being present was fundamental
> > for portability and cross-compatibility. Then, it shrinked to
> >
On 15/05/2023 19:00, Simon McVittie wrote:
> On Sun, 14 May 2023 at 23:37:34 +0200, Josh Triplett wrote:
>> People build things on Debian that are not Debian packages. People
>> compile binaries on Debian, and expect them to work on any system that
>> has sufficiently new libraries.
>
> *raises ha
Jeremy Stanley writes:
> Throwing another common one on the heap, similar to the previous Steam
> example, Python wheels with compiled extensions are often distributed on
> PyPI for a fictional "manylinux" platform which indicates they're
> intended to be usable on most GNU/Linux distributions (t
On 2023-05-16 17:05:25 -0700 (-0700), Russ Allbery wrote:
[...]
> Well, believe what you believe, but I literally do that daily, as
> does anyone else who regularly uses software from a Rust or Go
> ecosystem. Not a single work day goes by without me running, on
> some random Ubuntu or Red Hat or
Hi all,
first of all thank you for this great thread. While I could feel some
tension while reading it, it's completely normal and I've learned a lot.
I have a question though: if /lib64/ld-linux-x86-64.so.2 is already a
symlink on non-merged-/usr systems, pointing to
/lib/x86_64
Luca Boccassi writes:
> It does say something interesting. When we started, the assertion was
> that packages not relying on the symlink being present was fundamental
> for portability and cross-compatibility. Then, it shrinked to
> portability and cross-compatibility of a subset of packages. Now
On Tue, 16 May 2023 at 09:27, Simon McVittie wrote:
>
> On Tue, 16 May 2023 at 02:50:48 +0100, Luca Boccassi wrote:
> > This sounds like a very interesting use case, and the first real one
> > mentioned, which is great to see - but I do not fully follow yet, from
> > what you are saying it seems t
On Tue, 16 May 2023 at 04:22, Russ Allbery wrote:
> Luca Boccassi writes:
> > On Mon, 15 May 2023 at 16:18, Russ Allbery wrote:
>
> >> Note that we're not talking about complicated packages with lots of
> >> runtime like, say, Emacs. As I understand it your proposal wouldn't
> >> change PT_INTE
Didier 'OdyX' Raboud writes:
> This has existed in a (now distant) past as the "Linux Distribution
> Checker", in the context of the Linux Standard Base, that Debian and
> Ubuntu stopped caring about in late 2015.
Ah, yes, thank you, that makes sense.
> I'm not aware of more recent efforts in t
Le mardi, 16 mai 2023, 17.06:38 h CEST Russ Allbery a écrit :
> I don't know if anyone has written an ABI compliance test for binaries.
> That sounds like something that would be in scope for the Linux Test
> Project, though, and it's possible their existing tests do some of this.
This has existed
James Addison writes:
> We've almost certainly all encountered limitations in upstream
> specifications and wondered when it's worth attempting a perceived
> improvement despite potential friction.
> If Debian did want/need to change the PT_INTERP path, is there a way to
> achieve that in both a
On Tue, 16 May 2023 at 02:50:48 +0100, Luca Boccassi wrote:
> This sounds like a very interesting use case, and the first real one
> mentioned, which is great to see - but I do not fully follow yet, from
> what you are saying it seems to me that what you need is for your
> binaries to use the usual
On Tue, 16 May 2023 at 04:22, Russ Allbery wrote:
>
> > It did look like a veto to me. More importantly, isn't relying on
> > passersby to spot alleged harmful changes dangerous, especially for
> > undocumented, uncodified and untested use cases, like unspecified and
> > vague cross-compatibility
Hi Steve
On Mon, May 15, 2023 at 02:01:15AM +0100, Steve McIntyre wrote:
> Russ has described copying *binaries* out of packages and running them
> elsewhere. I've done that too, from time to time. This is one of the
> things made possible by the ABI contract being followed.
And nothing in that r
I'm dropping the TC bug from this thread, since I don't think it has
anything to do with that discussion at this point. I probably should also
change the Subject line, but I'm keeping it to make it easier for the
people who want to tune out this thread, since I very much doubt they want
to tune ba
On Mon, 15 May 2023 at 18:54, Simon McVittie wrote:
>
> On Sun, 14 May 2023 at 23:37:34 +0200, Josh Triplett wrote:
> > People build things on Debian that are not Debian packages. People
> > compile binaries on Debian, and expect them to work on any system that
> > has sufficiently new libraries.
On Mon, 15 May 2023 at 16:18, Russ Allbery wrote:
>
> Luca Boccassi writes:
> > On Mon, 15 May 2023 at 02:26, Russ Allbery wrote:
>
> >> (Also, no slight on the GUIX folks, but GUIX is not exactly an, uh,
> >> major player in Linux distributions, and I'm not sure how much they
> >> care about co
On Mon, 15 May 2023 02:42:27 +0200,
Luca Boccassi wrote:
>
> On Mon, 15 May 2023 at 01:14, Russ Allbery wrote:
>
> > An obvious specific example of such a system would be one that didn't
> > merge /usr and thus only had /lib64/ld-linux-x86-64.so.2 and not any other
> > path, but that's just one ob
On Mon, 15 May 2023 at 06:48:04 +0200, Johannes Schauer Marin Rodrigues wrote:
> Obviously, with Luca's proposal, binaries from packages built with a different
> dynamic linker path in them would not work on distributions without
> merged-/usr
> symlinks. But if the property of
r to be one of those,
to the extent of having a /lib64 solely for its benefit (on amd64)
even though by policy we don't generally use lib64.
(Incidentally, Steam's container runtime is always a merged-/usr
environment, to provide an environment that maximizes the probability
of any given s
Luca Boccassi writes:
> On Mon, 15 May 2023 at 02:26, Russ Allbery wrote:
>> (Also, no slight on the GUIX folks, but GUIX is not exactly an, uh,
>> major player in Linux distributions, and I'm not sure how much they
>> care about compatibility with anyone else.)
> This is a counter-example to c
On Mon, 15 May 2023 at 14:36, Steve McIntyre wrote:
>
> Hey Johannes,
>
> On Mon, May 15, 2023 at 06:48:04AM +0200, Johannes Schauer Marin Rodrigues
> wrote:
> >So did we not years ago decide, that the result of the "cross- and
> >inter-project discussion" is
without changing
>PT_INTERP. But what I do not understand about the argument against Luca's
>proposal is:
>
>Obviously, with Luca's proposal, binaries from packages built with a different
>dynamic linker path in them would not work on distributions without merged-/usr
>symlin
bootstrap problem can be solved in a way I envision without changing
PT_INTERP. But what I do not understand about the argument against Luca's
proposal is:
Obviously, with Luca's proposal, binaries from packages built with a different
dynamic linker path in them would not work on distributions
ot run on a system that doesn't have
> that path. So it's not like we have to carefully judge nuance here. Your
> argument, so far as I can tell, is basically "but no one will ever want to
> run those binaries on a non-/usr-merged system anyway," which is basically
> conceding t
s trivially and obviously
incompatible; the binary will simply not run on a system that doesn't have
that path. So it's not like we have to carefully judge nuance here. Your
argument, so far as I can tell, is basically "but no one will ever want to
run those binaries on a non
I'm *trying* to assume good faith here, but I'm running out of energy
to do so.
On Mon, May 15, 2023 at 01:42:27AM +0100, Luca Boccassi wrote:
>On Mon, 15 May 2023 at 01:14, Russ Allbery wrote:
>
>> Incidentally, that remains true even if we only do that in distribution
>> packages. I certainly
On Mon, May 15, 2023 at 12:24:15AM +0100, Luca Boccassi wrote:
>On Sun, 14 May 2023 at 22:37, Josh Triplett wrote:
>
>> The x86-64 ABI is set. Feel free to make the case to the next
>> architecture designer that their new ABI should have the dynamic linker
>> in `/usr/lib`. That would *not* have t
On Mon, 15 May 2023 at 01:14, Russ Allbery wrote:
>
> Luca Boccassi writes:
>
> > Why would "software compiled on Debian" fail to work in other
> > environments? Well, there are many reasons actually, people invented
> > containers/flatpaks/snaps exactly for that reason. But nothing do with
> > a
On Mon, 15 May 2023 at 01:07, Peter Pentchev wrote:
>
> On Mon, May 15, 2023 at 12:24:15AM +0100, Luca Boccassi wrote:
> > On Sun, 14 May 2023 at 22:37, Josh Triplett wrote:
> > >
> > > On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote:
> > > > The loader is still available via the ol
Luca Boccassi writes:
> Why would "software compiled on Debian" fail to work in other
> environments? Well, there are many reasons actually, people invented
> containers/flatpaks/snaps exactly for that reason. But nothing do with
> anything discussed here though, as far as I can tell?
My underst
On Mon, May 15, 2023 at 12:24:15AM +0100, Luca Boccassi wrote:
> On Sun, 14 May 2023 at 22:37, Josh Triplett wrote:
> >
> > On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote:
> > > The loader is still available via the old path, so external/third
> > > party/local/other software works
On Sun, 14 May 2023 at 22:37, Josh Triplett wrote:
>
> On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote:
> > The loader is still available via the old path, so external/third
> > party/local/other software works unchanged. This should negatively
> > only affect our 1st party packages,
On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote:
> The loader is still available via the old path, so external/third
> party/local/other software works unchanged. This should negatively
> only affect our 1st party packages, when running on a non-merged
> distro.
> And are _all_ our pa
On 2023-05-12 Ansgar wrote:
[...]
> The core issue as I see it is as follows:
[...]
> Do you think this summary of the issue is right?
I think Simon's reading of the situation as posted in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035904#30
makes a lot of sense.
cu Andreas
--
`What a g
t;On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote:
> >> >>On Fri, 12 May 2023 at 09:40, Steve McIntyre wrote:
> >> >>>
> >> >>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
> >> >>> >
> >> >
On Fri, May 12, 2023 at 03:29:29PM +0100, Steve McIntyre wrote:
> >> >Oh holy fuck.
> So why the hell do you want to break this in the first place?
> You're wilfully missing the point, and you know it.
> I have better things to do than argue about this. I refuse to engage
> with this right now. Yo
;On Fri, 12 May 2023 at 09:40, Steve McIntyre wrote:
>> >>>
>> >>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
>> >>> >
>> >>> >The core issue as I see it is as follows:
>> >>> >
>> >>> >-
> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
> >>> >
> >>> >The core issue as I see it is as follows:
> >>> >
> >>> >- Debian has decided to support only merged-/usr, including possibly
> >>> > moving /bin/sh
t;> >The core issue as I see it is as follows:
>>> >
>>> >- Debian has decided to support only merged-/usr, including possibly
>>> > moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2
>>> > as the interpreter in bin
>> >The core issue as I see it is as follows:
> >> >
> >> >- Debian has decided to support only merged-/usr, including possibly
> >> > moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2
> >> > as the interpreter in bin
On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote:
>On Fri, 12 May 2023 at 09:40, Steve McIntyre wrote:
>>
>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
>> >
>> >The core issue as I see it is as follows:
>> >
>> >- Debian
On Fri, 12 May 2023 at 09:40, Steve McIntyre wrote:
>
> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
> >
> >The core issue as I see it is as follows:
> >
> >- Debian has decided to support only merged-/usr, including possibly
> > moving /bin/sh
On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote:
>
>The core issue as I see it is as follows:
>
>- Debian has decided to support only merged-/usr, including possibly
> moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2
> as the interpreter in binar
and to debian-dpkg with
> a proposal to avoid having to have such a vote.
That seems to be about an implementation detail on how to apply the
patch. I don't think that is the core of the issue?
The core issue as I see it is as follows:
- Debian has decided to support only merged-/usr, in
Hello,
On Wed 10 May 2023 at 11:47PM +02, Ansgar wrote:
> Cool, then let's ask tech-ctte.
>
> Dear ctte, please consider overruling the dpkg maintainer to include
> the patch from #994388[1].
>
> Thanks,
> Ansgar
>
> [1]: https://bugs.debian.org/994388#397
This would require a new, maintainer-
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 part and I think I objected to that at the time.
> Nonetheless, one bad decision doesn't mean that it is Debia
On Wed, 2022-04-06 at 03:04 -0700, Krzysztof Sobiecki wrote:
> Hi,
> I saw warning and it advised me to use dpkg-fsys-usrunmess:
> But now I see:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008486
>From the link above:
"
Hi,
the `dpkg-fsys-usrunmess` program should include a warning tha
Andrey Rahmatullin writes:
> On Wed, Apr 06, 2022 at 04:02:23PM +0200, Bjørn Mork wrote:
>> > Sorry, blame the dpkg maintainer.
>>
>> Is that how we discuss technical issues around here?
> This is not a technical issue.
Ah, sorry. I mistook this for the "Discussion about technical
development t
On Wed, Apr 06, 2022 at 04:02:23PM +0200, Bjørn Mork wrote:
> > Sorry, blame the dpkg maintainer.
>
> Is that how we discuss technical issues around here?
This is not a technical issue.
--
WBR, wRAR
signature.asc
Description: PGP signature
Marco d'Itri writes:
> Sorry, blame the dpkg maintainer.
Is that how we discuss technical issues around here?
Bjørn
As a Debian user I'm confused and a bit angry.
And you have every right to be. Sorry, blame the dpkg maintainer.
> What is way forward?
Merged /usr.
--
ciao,
Marco
signature.asc
Description: PGP signature
On Wed, Apr 06, 2022 at 12:03:55PM +0200, Krzysztof Sobiecki wrote:
> Hi,
> I saw warning and it advised me to use dpkg-fsys-usrunmess:
> But now I see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008486
> And even without that there are problems with that tool:
> https://bugs.debian.org/cgi
Hi,
I saw warning and it advised me to use dpkg-fsys-usrunmess:
But now I see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008486
And even without that there are problems with that tool:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991218
https://bugs.debian.org/cgi-bin/bugreport.cgi?bu
> "Zack" == Zack Weinberg writes:
Zack> Maybe it was not obvious to anyone in 2016 that the package
Zack> database being inconsistent with the filesystem could cause
Zack> actual data loss. However, I think it was the responsibility
Zack> of the developers of usrmerge to find
Ansgar writes:
> So I do not think there should be a command-line option for this; unless
> it would behave like `--add-architecture` and register the setting
> somewhere.
Agreed.
I also think it needs to be a two-phase thing, because dpkg has to convert
its internal database to respect the new
to exist as command-line options just like --path-exclude does.
I would expect using --path-exclude when installing individual packages
to work: you just don't get the files from that package. (I haven't
tried.)
Merged-/usr (or --path-alias as you propose) does not work like this:
Unli
kage contents, their metadata and maintainer scripts
> but does not need magic from the outside other than standardized
> interfaces. Requiring the merged-/usr setup to be done by the bootstrap
> script would be a step backwards.
I understand why you want this, but unfortunately it doesn&
ts,
their metadata and maintainer scripts but does not need magic from the outside
other than standardized interfaces. Requiring the merged-/usr setup to be done
by the bootstrap script would be a step backwards. Think about the following
points:
* you create a Debian unstable chroot using snapsho
ot;/usr merge", causing /bin/bash to be
unpacked as /usr/bin/bash while creating a symbolic link
/bin -> usr/bin.
With that, I believe a full implementation of merged-usr for all known
architectures would be to install something like this, perhaps via
base-files:
# in /etc/dpkg/dp
ic.
All that I mean by special-case is that I think it would be a mistake to
try to shoehorn support for merged-/usr into some pre-existing dpkg
concept. The merged-/usr links are special relative to other files that
dpkg is managing and need to be treated with special care. We should add
a new
Hi,
On Sat, Nov 20, 2021 at 09:22:27AM -0800, Russ Allbery wrote:
> The drawback here is that dpkg is going to rewrite all paths like /lib64
> to /usr/lib64, which would naively *also* apply to the base-files
> package when it looks at that package, but that can't be allowed because
> now
ete.
I'm going to make the following assumptions:
* We have some mechanism to put dpkg into what I've been calling
merged-/usr mode. In this mode, it pre-filters all input paths from
whatever source (including arguments to dpkg-divert,
update-alternatives, etc.) and canonicalizes t
ed
one-time conversion of the state database.
It involves a new filter, applied whenever a package is installed, that
changes all the paths in the package to their merged-/usr paths, something
that seems like it should be done before any other package processing.
Once that's done, why would a
Hi,
> > (I've used /bin -> /usr/bin as an example, but the canonicalization must
> > deal with the other merged paths too.)
/lib and /lib64 are a bit special, because they are part of the ELF ABI,
and any manipulation of these paths needs to be atomic.
Bootstrapping a new Debian system works by
t and we don't intend to support going
backwards (in other words, once you have merged /usr, it's not supported
to turn /bin, etc., back into regular directories again).
Therefore, dpkg can be configured with the list of the symlinks that
*must* exist for it to be willing to operate on
Hi,
On Fri, Nov 19, 2021 at 12:28:56PM -0700, Sam Hartman wrote:
> But we could you know fix dpkg:-)
> I'm sure that will be painful at the political level, but personally I
> think it needs doing.
I think the main blocker at the moment is that the dpkg change *also*
has the potential to break a
* Russ Allbery [2021-11-19 11:46]:
I also don't understand why this isn't the correct solution. It seems
obvious to me that we should simply teach dpkg about path aliases and have
it update both its internal state and its processing of new packages to
canonicalize paths so that it has an accura
use problems under
>>> conditions which we can reasonably expect to occur shortly after
>>> the release of bookworm.
>>
>> Why would the release of bookworm make any difference?
>
> Up until the release of bookworm, all Debian packages must be
> constructed on t
;> the release of bookworm.
>
> Why would the release of bookworm make any difference?
Up until the release of bookworm, all Debian packages must be
constructed on the assumption that they _might_ be unpacked on a
system that has not yet been converted to merged /usr. Particularly
for prio
Richard Laager writes:
> Is this particularly hard to fix, though?
> Can't we just do something like the following pseudo-code:
[...]
> (I've used /bin -> /usr/bin as an example, but the canonicalization must
> deal with the other merged paths too.)
> The second bit ensures that all new opera
Hi
On 18-11-2021 22:44, Marco d'Itri wrote:
On Nov 18, Zack Weinberg wrote:
Are you seriously claiming that that phenomenon is not a severity:critical bug?
I am seriously claming that whatever you are referring to, if true, is
such a contrived example that does not actually happen in real li
> "Michael" == Michael Biebl writes:
Michael> Am 17.11.2021 um 19:57 schrieb Sam Hartman:
Michael> AIUI simply moving files from / to /usr within the same
Michael> package is not problematic.
Sorry, I was being overly simplistic.
I think your understanding is mostly correct.
You
> "Marco" == Marco d'Itri writes:
Marco> On Nov 18, Zack Weinberg wrote:
>> Are you seriously claiming that that phenomenon is not a
>> severity:critical bug?
Marco> I am seriously claming that whatever you are referring to, if
Marco> true, is such a contrived example tha
On 2021-11-19 15:37 +0100, Michael Biebl wrote:
> On 19.11.21 11:58, Philip Hands wrote:
>> Ansgar writes:
>>
* doing this will, in a non-negligible number of cases, trigger the
bug to manifest on systems where that package is upgraded from a
version where the move had not taken pl
On Fri, 19 Nov 2021 11:58:39 +0100, Philip Hands
wrote:
>Given that these bugs are going to be utter bastards to reproduce, and
>you can be sure that we'll have enough diversity in installed systems
>that some people are going to manage to be sufficiently unlucky, it
>would be nice to know the sor
On 19.11.21 11:58, Philip Hands wrote:
Ansgar writes:
* doing this will, in a non-negligible number of cases, trigger the
bug to manifest on systems where that package is upgraded from a
version where the move had not taken place to one where it has.
Why do you claim that?
Given packages al
On Fri, Nov 19, 2021 at 10:06:13AM +0100, Ansgar wrote:
> Given packages already did such moves in the last years and you claim
> this happens in a non-negligible number of cases, could you please
> point to some examples where this already happens in practice?
You need a / → /usr¹ and a pkg-a → p
Ansgar writes:
>> * doing this will, in a non-negligible number of cases, trigger the
>> bug to manifest on systems where that package is upgraded from a
>> version where the move had not taken place to one where it has.
>
> Why do you claim that?
>
> Given packages already did such moves in the
On Thu, 2021-11-18 at 23:01 -0500, The Wanderer wrote:
> * to date, package maintainers have not yet begun moving
> already-packaged files from / to /usr/ (specifically because doing so
> would break systems that have not yet been migrated to merged-/usr,
> and Debian has not yet d
On Nov 18, Zack Weinberg wrote:
> Are you seriously claiming that that phenomenon is not a severity:critical
> bug?
I am seriously claming that whatever you are referring to, if true, is
such a contrived example that does not actually happen in real life
(or at least, it does not happen frequen
On 2021-11-18 at 20:06, Luca Boccassi wrote:
> On Thu, 2021-11-18 at 16:23 -0500, Zack Weinberg wrote:
>
>> Luca Bocassi wrote:
>>> [merged /usr] is the default. It has been the default for
>>> multiple releases of multiple distributions. All Ubuntu
>>>
On Thu, 2021-11-18 at 16:23 -0500, Zack Weinberg wrote:
Luca Bocassi wrote:
...
> [merged /usr] is the default. It has been the
> default for multiple releases of multiple distributions. All Ubuntu
> installations that were not using this default are now forcibly
> converted upon upgr
Luca Bocassi wrote:
...
> [merged /usr] is the default. It has been the
> default for multiple releases of multiple distributions. All Ubuntu
> installations that were not using this default are now forcibly
> converted upon upgrade to 21.10.
>
> And yet nobody has actua
Marco d'Itri wrote:
> On Nov 18, Zack Weinberg wrote:
>> as it has proven to be a genuinely critical problem
> No, it has not.
In the previous long thread on debian-devel on this subject, someone posted a
step-by-step recipe to reproduce a phenomenon where a file that has been moved
(in its pac
On Thu, 2021-11-18 at 13:09 +0100, Marco d'Itri wrote:
> On Nov 18, Zack Weinberg wrote:
>
> > And, as it has proven to be a genuinely critical problem, it is also their
> No, it has not.
Indeed - it seems to me there's a convenient tendency to forget that
this is not something new that has neve
On Nov 18, Zack Weinberg wrote:
> And, as it has proven to be a genuinely critical problem, it is also their
No, it has not.
--
ciao,
Marco
signature.asc
Description: PGP signature
Michael Biebl writes:
> Am 17.11.2021 um 19:57 schrieb Sam Hartman:
>> The question is whether we ever get to a place where people can update
>> files in a package currently installed to /bin/foo and instead install
>> them to /usr/bin/foo.
>> We have a consensus that dpkg bugs make that a bad ide
On 11/17/21 8:18 PM, Zack Weinberg wrote:
However, I think it was the responsibility of the developers of usrmerge
to find out how bad that problem actually was, rather than dismissing it.
And, as it has proven to be a genuinely critical problem, it is also their
responsibility to fix it, per the
; lots of accidental breakage in unstable post-bookworm.
Sam> I don't like that outcome either.
Sam> I think that we have reasonable mitigations for the specific problem you
Sam> describe.
Sam> In particular, we do as I understand it have QA plans to build both with
Sam> merged
Zack> lots of accidental breakage in unstable post-bookworm, as
Zack> packages are rebuilt on systems that now have /bin a symlink.
I don't like that outcome either.
I think that we have reasonable migigations for the specific problem you
describe.
In particular, we do as I und
at this point, pull usrmerge
from testing and stable, push point updates to the installers for all supported
releases to flip the default back to non-merged /usr, and advise the installed
base to run dpkg-fsys-usrunmess before their next apt upgrade. It'd be ugly
but it might well be *less
Am 17.11.2021 um 19:57 schrieb Sam Hartman:
The question is whether we ever get to a place where people can update
files in a package currently installed to /bin/foo and instead install
them to /usr/bin/foo.
We have a consensus that dpkg bugs make that a bad idea.
Is that really so? If I'm not
> "Marco" == Marco d'Itri writes:
Marco> On Nov 10, Sam Hartman wrote:
>> I'm sorry, but I think the only way in which that horse is dead
>> is that no one has proposed patches to dpkg.
Marco> Indeed, because the sides of this argument are like three
Marco> people (one of
> "Zack" == Zack Weinberg writes:
Zack> The existence of the bug is not in question. A step-by-step
Zack> reproduction recipe was posted in the previous thread. Losing
Zack> files from Essential packages when they are upgraded is
Zack> severity:critical
Agreed so far.
Z
1 - 100 of 677 matches
Mail list logo
