> "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
On Mon, 2021-11-22 at 12:24 +, Simon McVittie wrote:
> Options to make path A an alias for path B would be a lot like --path-
> exclude in that they really only make sense in a configuration file in
> /etc/dpkg/dpkg.cfg.d, although for symmetry they would presumably also
> have to exist as comm
Johannes Schauer Marin Rodrigues writes:
> Please don't. Since 2014 it is possible to create a Debian chroot
> without taking care of the unpack order and without running any special
> setup beforehand that cannot be put into apt or dpkg itself (like
> creating /var/lib/dpkg/info which is not nee
Quoting Russ Allbery (2021-11-20 18:22:27)
> * Create a new essential package that contains these symlinks and that
> needs to be unpacked before any binaries are executed in the target file
> system. This has many of the advantages and drawbacks of the approach
> of putting the symlinks in
On Sat, 20 Nov 2021 at 14:54:30 -0800, Russ Allbery wrote:
> That would make it akin to dpkg
> --add-architecture, which feels like a good model (although as you mention
> I don't think we want --remove-architecture).
Instead of dpkg --add-architecture, which is a top-level "verb" like
dpkg --remo
Gabor Gombas writes:
> If you replace "rewrite /lib64 to /usr/lib64" with "rewrite /lib64/* to
> /usr/lib64/*", then this can easily be avoided.
True, although I think you still want to ensure that dpkg never messes
with those links. I don't think you want base-files to be able to drop
one of t
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
Russ Allbery writes:
> Well, bootstrapping a new Debian system involves running a tool that
> bootstraps a new Debian system. I think you're constraining the problem
> too much.
> It's a nice property that everything on the system comes straight from a
> Debian package, but it's not a strict re
Simon Richter writes:
> Bootstrapping a new Debian system works by unpacking Essential packages
> with ar+tar, i.e. not using dpkg. These packages will always be unpacked
> to the file names listed inside the packages.
Well, bootstrapping a new Debian system involves running a tool that
bootstra
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
Simon Richter writes:
> I think the main blocker at the moment is that the dpkg change *also*
> has the potential to break a lot of things if it isn't carefully
> designed.
I think you can simplify that problem space considerably because we know
exactly what symlinks we care about and we don't i
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
On Fri, Nov 19, 2021, at 3:23 PM, Zack Weinberg wrote:
> On Thu, Nov 18, 2021, at 8:06 PM, Luca Boccassi wrote:
>>> On Thu, 2021-11-18 at 16:23 -0500, Zack Weinberg wrote:
>>> Luca Bocassi wrote:
>>> ...
nobody has actually seen [the file disappearance bug]
happen, to the best of my knowl
On Thu, Nov 18, 2021, at 8:06 PM, Luca Boccassi wrote:
>> On Thu, 2021-11-18 at 16:23 -0500, Zack Weinberg wrote:
>> Luca Bocassi wrote:
>> ...
>>> nobody has actually seen [the file disappearance bug]
>>> happen, to the best of my knowledge.
>>
>> I already explained why that doesn't prove the bug
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 declared that such
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
>>> installations that were not using this def
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 upgrade to 21.10.
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 actually seen [the file disappear
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
>> "Sam" == Sam Hartman wrote:
>> "Zack" == Zack Weinberg writes:
Sam> There's a third option. We sit around in the state where /bin is
Sam> a symlink, but where you cannot move files to /usr paths in the
Sam> package system until the bug is fixed.
Zack> I guess that is a potential out
> "Zack" == Zack Weinberg writes:
Zack> On Wed, Nov 17, 2021, at 1:37 PM, Sam Hartman wrote:
>>> "Zack" == Zack Weinberg writes:
Zack> Therefore: either someone fixes the bug, or the transition
Zack> will have to be canceled. It appears to me that the tech ctte
Zack>
On Wed, Nov 17, 2021, at 1:37 PM, Sam Hartman wrote:
>> "Zack" == Zack Weinberg writes:
> Zack> Therefore: either someone fixes the bug,
> Zack> or the transition will have to be canceled. It appears to me
> Zack> that the tech ctte agrees with all of this.
>
> There's a third opt
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
Luca Bonassi wrote:
> may I also remind participants in this thread that according to our
> Constitution (2.1), no project member is obliged to do work on
> anything they don't want to
Yes, and it follows that the people who want a change to happen are
the people who will have to do the work to ma
On Fri, 2021-11-12 at 08:38 +0100, Ansgar wrote:
> Hi Svante,
>
> On Thu, 2021-11-11 at 23:22 +0100, Svante Signell wrote:
> > I'm not sure he has the skill or experience enough to submit a patch to
> > dpkg. Complaining is much easier than proposing something constructive.
>
> I would like to re
On Fri, 2021-11-12 at 04:57 +0100, Guillem Jover wrote:
>
> On Sun, 2021-08-22 at 11:21:38 +0100, Luca Boccassi wrote:
> > On Sat, 2021-08-21 at 22:57 +0200, Guillem Jover wrote:
> > > On Sat, 2021-08-21 at 18:47:50 +0100, Luca Boccassi wrote:
> > > > The bug is real, nobody doubts that - it has b
Hi Svante,
On Thu, 2021-11-11 at 23:22 +0100, Svante Signell wrote:
> I'm not sure he has the skill or experience enough to submit a patch to
> dpkg. Complaining is much easier than proposing something constructive.
I would like to remind you that Debian expects somewhat decent behavior
of contri
unblock 848622 by 134758
thanks
On Sun, 2021-08-22 at 11:21:38 +0100, Luca Boccassi wrote:
> On Sat, 2021-08-21 at 22:57 +0200, Guillem Jover wrote:
> > On Sat, 2021-08-21 at 18:47:50 +0100, Luca Boccassi wrote:
> > > The bug is real, nobody doubts that - it has been filed on dpkg 20
> > > years a
On Thu, 2021-11-11 at 16:07 -0500, Zack Weinberg wrote:
> Marco d'Itri wrote:
> > Since some significant work on dpkg is reasonably not forthcoming
>
> Yeah, because _you,_ Marco, prefer to spend your time trying to
> gaslight the project into thinking there isn't a critical-severity
> bug in usr
Marco d'Itri wrote:
> 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.
> Indeed, because the sides of this argument are like three people (one of
> them being the dpkg maintainer) versus everybody el
On Wed, Nov 10, 2021 at 01:48:07AM +0200, Uoti Urpala wrote:
> David Kalnischkies wrote:
> > As the transition hasn't started everyone not already merged is currently
> > deferring it. That is true for those who upgrade daily as well as for
> > those people who seemingly only upgrade their sid syst
On Wed, Nov 10, 2021 at 07:01:15PM +0100, Marco d'Itri wrote:
> 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.
> Indeed, because the sides of this argument are like three people (one of
> them b
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.
Indeed, because the sides of this argument are like three people (one of
them being the dpkg maintainer) versus everybody else.
Since some significant wo
> "Marco" == Marco d'Itri writes:
Marco> On Nov 08, Simon Richter wrote:
>> Yes, but the conversion needs to be performed by dpkg, because
>> the usrmerge
Marco> Please kindly stop beating this long-dead horse.
I'm sorry, but I think the only way in which that horse is dead
On Tue, Nov 09, 2021 at 08:44:52PM +, Simon McVittie wrote:
> On Tue, 09 Nov 2021 at 19:01:18 +0100, David Kalnischkies wrote:
> > On Tue, Nov 09, 2021 at 03:21:25PM +, Simon McVittie wrote:
> > (Minus that for 12 it is technically still supported as long as it
> > remains 12
>
> No, it d
On Tue, 09 Nov 2021 at 19:01:18 +0100, David Kalnischkies wrote:
> On Tue, Nov 09, 2021 at 03:21:25PM +, Simon McVittie wrote:
> > > As I see it the CTTE decision effectively allows the transition to be
> > > deferred until the moment you want to upgrade to 13.
> >
> > I think you mean: until
On Tue, 09 Nov 2021 at 20:27:24 +0100, Bastian Blank wrote:
> On Tue, Nov 09, 2021 at 08:19:40PM +0100, Michael Biebl wrote:
> > I'm worried that by saying that unmerged is still supported in 12, we open a
> > can of worms and just punt this down to yet another release cycle.
>
> No, unmerged will
On Tue, Nov 09, 2021 at 08:19:40PM +0100, Michael Biebl wrote:
> I'm worried that by saying that unmerged is still supported in 12, we open a
> can of worms and just punt this down to yet another release cycle.
No, unmerged will not be supported in 12. Having the ability to create
something does
On 09.11.21 19:01, David Kalnischkies wrote:
(Minus that for 12 it is technically still supported as long as it
remains 12, but those who have to know will know that and everyone else
is better of following the default anyhow)
I'm worried that by saying that unmerged is still supported in 1
On Tue, Nov 09, 2021 at 03:21:25PM +, Simon McVittie wrote:
> > As I see it the CTTE decision effectively allows the transition to be
> > deferred until the moment you want to upgrade to 13.
>
> I think you mean: until the moment you want to upgrade to testing after
> Debian 12 release day. Th
(Speaking only for myself, not the TC as a whole - but I wrote the first
draft of what became the TC resolution we're discussing.)
On Tue, 09 Nov 2021 at 15:19:53 +0100, David Kalnischkies wrote:
> On Mon, Nov 08, 2021 at 12:56:49PM +0100, Marco d'Itri wrote:
> > On Nov 08, Simon Richter wrote:
>
On Mon, Nov 08, 2021 at 12:56:49PM +0100, Marco d'Itri wrote:
> On Nov 08, Simon Richter wrote:
> > Right now, it is sufficient to preseed debconf to disallow the usrmerge
> > package messing with the filesystem tree outside dpkg. Managed installations
> > usually have a ready-made method to do so
On Nov 08, Simon Richter wrote:
> Yes, but the conversion needs to be performed by dpkg, because the usrmerge
Please kindly stop beating this long-dead horse.
--
ciao,
Marco
signature.asc
Description: PGP signature
Hi,
On 11/8/21 12:56 PM, Marco d'Itri wrote:
Right now, it is sufficient to preseed debconf to disallow the usrmerge
package messing with the filesystem tree outside dpkg. Managed installations
usually have a ready-made method to do so.
This is not really relevant, since the conversion is ma
On Nov 08, Simon Richter wrote:
> Right now, it is sufficient to preseed debconf to disallow the usrmerge
> package messing with the filesystem tree outside dpkg. Managed installations
> usually have a ready-made method to do so.
This is not really relevant, since the conversion is mandatory.
The
Hi,
On 11/8/21 12:03 AM, Marco d'Itri wrote:
I have been asked to remove from the usrmerge package the debconf
question which asks to confirm the conversion.
Does anybody REALLY believe that it should not be removed?
While it may be more convenient for home users to not be bothered with
ques
On 2021-08-26 Timo Röhling wrote:
[...]
> However, Guillem also seems to think that dpkg can manage file
> symlinks in a real directory better than an directory symlinks in /,
> which is why he proposed symlink farms in the first place.
Hello,
Afaiui, the symlink farm would just work from dpkg's
Hi,
* Sam Hartman [2021-08-26 08:56]:
That may not matter so much for Debian (at least in some people's minds)
but being compatible with the rest of the world has enough value in this
instance that I consider the issue moot.
I agree that this is a very convincing argument. A considerably
weake
> "Timo" == Timo Röhling writes:
Timo> However, Guillem also seems to think that dpkg can manage file
Timo> symlinks in a real directory better than an directory symlinks
Timo> in /, which is why he proposed symlink farms in the first
Timo> place. Assuming dpkg implements the
On Thu, 2021-08-26 at 14:51 +0200, Simon Richter wrote:
> Hi,
>
> On 8/26/21 1:17 PM, Luca Boccassi wrote:
>
> > > Ideally the question whether a system works correctly would be a
> > > technical, not a political one that is based on a majority vote of
> > > people who do not look behind the faca
* Simon Richter [2021-08-26 14:51]:
It makes a lot more sense to have a dpkg-internal tool that can
investigate the differences between the file system and the dpkg
database, resolve conflicts (possibly in an interactive process when
required by a corner case like the one I mentioned earlier
Hi,
On 8/26/21 1:17 PM, Luca Boccassi wrote:
Ideally the question whether a system works correctly would be a
technical, not a political one that is based on a majority vote of
people who do not look behind the facade.
Precisely - and the correct technical question is, how many bug reports
w
On Thu, 2021-08-26 at 13:50 +0200, Philip Hands wrote:
> Luca Boccassi writes:
>
> > On Thu, 2021-08-26 at 12:16 +0200, Simon Richter wrote:
> > > Hi,
> > >
> > > On 8/26/21 8:38 AM, Marco d'Itri wrote:
> > >
> > > > > By my definition, these have never been working correctly, but
> > > > > sem
Luca Boccassi writes:
> On Thu, 2021-08-26 at 12:16 +0200, Simon Richter wrote:
>> Hi,
>>
>> On 8/26/21 8:38 AM, Marco d'Itri wrote:
>>
>> > > By my definition, these have never been working correctly, but
>> > > semantics I guess.
>>
>> > It is not semantics. You keep saying that countless De
On Thu, 2021-08-26 at 12:16 +0200, Simon Richter wrote:
> Hi,
>
> On 8/26/21 8:38 AM, Marco d'Itri wrote:
>
> > > By my definition, these have never been working correctly, but
> > > semantics I guess.
>
> > It is not semantics. You keep saying that countless Debian and Ubuntu
> > systems are no
Hi,
On 8/26/21 8:38 AM, Marco d'Itri wrote:
By my definition, these have never been working correctly, but
semantics I guess.
It is not semantics. You keep saying that countless Debian and Ubuntu
systems are not working correctly, but since this obviously does not
reflect the experience of t
On Aug 26, Guillem Jover wrote:
> By my definition, these have never been working correctly, but
> semantics I guess.
It is not semantics. You keep saying that countless Debian and Ubuntu
systems are not working correctly, but since this obviously does not
reflect the experience of the owners o
Today's update, Debian test can't read my windows partition. I fix it
inside the bios configuration.
El mié, 25 de ago. de 2021 a la(s) 15:27, Aurelien Jarno (
aurel...@aurel32.net) escribió:
> On 2021-08-20 23:15, Simon Richter wrote:
> > I think that one of the release goals should be that any
Hi!
On Sun, 2021-08-22 at 09:18:25 +0200, Andreas Metzler wrote:
> Afaict we have still no idea on how to move on.
>
> 1 I think you agree that there is a significant number of usrmerged Debian
> installations out there. It does not really matter whether there are 7% or
> 40%. They exist and
Guillem Jover writes:
> The fact that the supporters of a *filesystem layout* have been happy to
> dismiss and ignore this and have been pushing for what I think can be
> easily described as the worst ever "transition" done in Debian, very
> sadly, for me this whole topic marks a before and after
Simon Richter writes:
> I'd expand the definition of Conflicts/Replaces though: packages that
> use names that conflict because of usrmerge would need to declare it,
> because as soon as we teach dpkg to recognize these conflicts, the
> packages would fail to install on stable.
Yes, that's proba
Hi,
On 25.08.21 18:57, Russ Allbery wrote:
The problem here is also that if there are two packages like that, on an
usrmerge system, we would not know this is happening.
I agree, of course, but I don't see a way in which Policy can help with
that problem unless this packaging decision was in
On Wed, Aug 25, 2021 at 09:57:09AM -0700, Russ Allbery wrote:
> Wouter Verhelst writes:
> > On Mon, Aug 23, 2021 at 08:23:50AM -0700, Russ Allbery wrote:
>
> >> If we tried to document every random bit of buggy packaging behavior
> >> anyone thought of in Policy, Policy would become unwieldy, so
On 2021-08-20 23:15, Simon Richter wrote:
> I think that one of the release goals should be that any freshly installed
> or upgraded system should have a dpkg database that is consistent with
> reality, and I'd prioritize that higher than actually finishing the
> transition, because as long as we c
On Wed, 2021-08-25 at 09:57:09 -0700, Russ Allbery wrote:
> Wouter Verhelst writes:
> > The problem here is also that if there are two packages like that, on an
> > usrmerge system, we would not know this is happening.
Also this does not need to come from "buggy" packaging practices.
> I agree,
Wouter Verhelst writes:
> On Mon, Aug 23, 2021 at 08:23:50AM -0700, Russ Allbery wrote:
>> If we tried to document every random bit of buggy packaging behavior
>> anyone thought of in Policy, Policy would become unwieldy, so I want to
>> verify here that someone really thought having one package
On Mon, Aug 23, 2021 at 08:23:50AM -0700, Russ Allbery wrote:
> Luca Boccassi writes:
>
> > Thank you - it has been brought up in this thread as an example of a
> > valid setup, so if it is not, I think it could be good to be extra clear
> > in the policy? How about the following:
>
> If we trie
On Tue, 24 Aug 2021 at 10:46:45 -0400, Theodore Ts'o wrote:
> the definition of usrmerged is
> relatively well understood (symlinks for /{bin,lib,sbin} to
> /usr/{bin,lib,sbin})
For completeness: also /libQUAL to usr/libQUAL, for each libQUAL
that either participates in multilib or contains ld.so(
On Tue, Aug 24, 2021 at 11:57:27AM +0200, Simon Richter wrote:
> Hi,
>
> On 8/24/21 2:48 AM, Theodore Ts'o wrote:
>
> > So in theory, if we had a program which looked for the top-level
> > symlinks /{bin,lib,sbin} -> /usr/{bin,lib,sbin}, and if they exist,
> > scans dpkg database is scanned l
Hi,
On 8/24/21 2:48 AM, Theodore Ts'o wrote:
So in theory, if we had a program which looked for the top-level
symlinks /{bin,lib,sbin} -> /usr/{bin,lib,sbin}, and if they exist,
scans dpkg database is scanned looking for of the form
/{bin,lib,sbin}/$1, and updates them with /usr/{bin,lib,sb
Hi,
* Theodore Ts'o [2021-08-23 20:48]:
I want to ask a potentially stupid question.
[...]
This is pretty much what I was wondering about in
https://lists.debian.org/debian-devel/2021/08/msg00372.html
You, however, phrased it much more eloquently than I could.
Cheers
Timo
--
⢀⣴⠾⠻⢶⣦⠀ ╭─
I want to ask a potentially stupid question.
As I understand things, the problem is that in a usrmerge'd file
system where we have the top-level symlinks /{bin,lib,sbin} which
point at /usr/{bin,lib,sbin}, the problem is if we have a package
which contains the file in /sbin/blart, it gets installe
Ansgar writes:
> Different, non-conflicting packages shipping binaries with the same name
> in /bin and /usr/bin (or similar) should be resolved for a while
> now. That as looked at when usrmerge was first introduced. I'm aware of
> one instance where this was intentional to prefer one program ov
Hi Russ,
On Mon, 2021-08-23 at 13:41 -0700, Russ Allbery wrote:
> Right now, in the absence of such a plan, it's obvious that having
> two
> unrelated packages (that do not Conflict) ship a binary with the same
> name
> in /bin and /usr/bin is not sensible, yes? (I believe that's the
> topic
> un
Simon Richter writes:
> It is less nonsensical because usrmerge exists, since we presumably
> don't want to keep the /bin paths in the packages, so at some point we
> need to move /bin/foo to /usr/bin/foo inside a package. That is safe
> with current dpkg, as dpkg will not delete /bin/foo if it
Hi,
On 23.08.21 17:23, Russ Allbery wrote:
[one package with /bin/foo, another with /usr/bin/foo]
This seems clearly nonsensical to me even if usrmerge was never on the
horizon, since which binary you got would randomly depend on the PATH
ordering and the order of /bin vs. /usr/bin in user-set
Tomas Pospisek wrote:
> On 22.08.21 00:11, Guillem Jover wrote:
>> I'm personally just not seeing such consensus, despite the attempts of
>> some to make it pass as so. My perception is that this topic has become
>> such a black hole of despair, that people that take issue with it, are
>> simply
* Ansgar [210823 11:16]:
> Hi Marvin,
>
> On Mon, 2021-08-23 at 10:29 -0400, Marvin Renich wrote:
> > Yet they cannot be counted on to work on Debian now, nor will they on
> > non- or partially-merged systems. You are saying "the end result is
> > thus, so the partially merged system must have t
Luca Boccassi writes:
> Thank you - it has been brought up in this thread as an example of a
> valid setup, so if it is not, I think it could be good to be extra clear
> in the policy? How about the following:
If we tried to document every random bit of buggy packaging behavior
anyone thought of
Hi Marvin,
On Mon, 2021-08-23 at 10:29 -0400, Marvin Renich wrote:
> Yet they cannot be counted on to work on Debian now, nor will they on
> non- or partially-merged systems. You are saying "the end result is
> thus, so the partially merged system must have this property."
No. I am comparing end
> "Simon" == Simon Richter writes:
>> I can see two arguments why we might need a dpkg update:
>>
>> 1) To fix bugs related to directory aliasing.
>>
>> I don't think that there is a consensus those bugs need to be
>> fixed to move forward. (Put another way it's not
* Ansgar [210822 17:29]:
> Hi,
>
> On Sun, 2021-08-22 at 12:29 -0400, Marvin Renich wrote:
> > * Ansgar [210822 05:08]:
> > > To get a filesystem layout equivalent to merged-/usr via symlinks
> > > farming *every* package shipping files in at least /usr/bin,
> > > /usr/sbin and possibly some of
1 - 100 of 287 matches
Mail list logo
