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
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
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
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
> "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
* 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
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
> > > > >
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>
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
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
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
> "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
> "Simon" == Simon Richter writes:
Simon> Current dpkg already has handling code so that /bin/foo ->
Simon> /usr/bin/foo is not a problematic move even on usrmerge'd
Simon> systems, so a possible policy would be to allow those and
Simon> disallow package splits, that way we
On Sun, 2021-08-22 at 19:10 -0700, Russ Allbery wrote:
> Luca Boccassi writes:
> > On Sun, 2021-08-22 at 07:45 -0700, Russ Allbery wrote:
>
> > > This is already the case. Policy 10.1:
>
> > > To support merged-/usr systems, packages must not install files in
> > > both /path and
Luca Boccassi writes:
> On Sun, 2021-08-22 at 07:45 -0700, Russ Allbery wrote:
>> This is already the case. Policy 10.1:
>>To support merged-/usr systems, packages must not install files in
>>both /path and /usr/path. For example, a package must not install both
>>/bin/example and
On Sun, 22 Aug 2021 19:02:18 -0400, Theodore Ts'o wrote:
> On Sun, Aug 22, 2021 at 12:26:46PM +0200, David Kalnischkies wrote:
> > So, when did you last log into your build chroot to upgrade dpkg and
> > apt first?
> Personally, I never upgrade build chroots between major versions. I
> just use
On Sun, Aug 22, 2021 at 12:26:46PM +0200, David Kalnischkies wrote:
>
> So, when did you last log into your build chroot to upgrade dpkg and
> apt first? And while at that, did you follow the release notes – from
> the future, as they have yet to be written for the release you are
> arguably
On Sun, 2021-08-22 at 12:42 +0200, Steve Cotton wrote:
> Am Sun, Aug 22, 2021 at 11:21:38AM +0100 schrieb Luca Boccassi:
> > On Sat, 2021-08-21 at 22:57 +0200, Guillem Jover wrote:
> > > Just like no one had detected the database corruption in Ubuntu
> > > before
> > > I spotted the problem via
On Sun, 2021-08-22 at 07:45 -0700, Russ Allbery wrote:
> Luca Boccassi writes:
>
> > I've asked this before - I might be very wrong, but I was under the
> > impression that having both /bin/foo and /usr/bin/foo (which is the
> > example mentioned) was already considered RC-buggy and needed
> >
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 stepping away.
Possibly. But for
Hi,
On 22.08.21 16:52, Simon Richter wrote:
The most generic approach would be to have a symlink farming mode in
dpkg, where it has a goal (as defined by a package) to create a symlink
/lib -> usr/lib, but while another package declares /lib to be a
directory, the directory has precedence
Hi,
On 22.08.21 05:10, Theodore Ts'o wrote:
So with the goal of trying to enumerate possible solutions, it sounds
some combination of:
(a) disallowing moving problematic files between packages, with possibly some
QA tools to enforce this
(b) keeping the next release cycle *short*, say
Luca Boccassi writes:
> I've asked this before - I might be very wrong, but I was under the
> impression that having both /bin/foo and /usr/bin/foo (which is the
> example mentioned) was already considered RC-buggy and needed fixing?
> Is that not the case?
This is already the case. Policy
Am Sun, Aug 22, 2021 at 11:21:38AM +0100 schrieb Luca Boccassi:
> On Sat, 2021-08-21 at 22:57 +0200, Guillem Jover wrote:
> > Just like no one had detected the database corruption in Ubuntu before
> > I spotted the problem via code review and analysis (which I guess in
> > your world translates to
On Sat, Aug 21, 2021 at 12:47:51PM -0400, Theodore Ts'o wrote:
> Personally, I *don't* have a problem about telling people to manually
> update dpkg, apt, and/or apt-get before they do the next major stable
> release (maybe it's because this is something I do as a matter of
> course; it's not that
On Sat, 2021-08-21 at 23:10 -0400, Theodore Ts'o wrote:
> On Sun, Aug 22, 2021 at 02:15:31AM +0200, Simon Richter wrote:
> >
> > The latter is what brought us into a situation where it is no
> > longer safe to
> > move files between packages and between aliased directories in the
> > same
> >
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:
> > On Sat, 2021-08-21 at 16:20 +0200, Wouter Verhelst wrote:
> > > I'm not saying the solution which the dpkg maintainers are
> > > proposing
> > > is the only valid solution, but
Hi,
* Simon Richter [2021-08-22 02:15]:
There are two issues here: dpkg not handling certain corner cases, and
the usemerge package modifying the file system, bypassing dpkg.
Maybe this question has been answered elsewhere, but I keep
wondering: What prevents dpkg from updating/reparing its
On Sat, 2021-08-21 at 20:45 +0100, Colin Watson wrote:
> On Sat, Aug 21, 2021 at 06:47:50PM +0100, Luca Boccassi wrote:
> > My recollection (which might be wrong, but a quick look at release
> > notes seems to support it with 11.04 having multiarch 2 years
> > before
> > Wheezy) is that Canonical
On 2021-08-22 Guillem Jover wrote:
[...]
> The huge majority of files under /lib* (which is the actual bulk of them)
> should require no symlink farms. Many of the ones under /bin and /sbin
> (we are talking about around 240 packages here) might be switchable w/o
> compat symlinks after careful
On Sun, Aug 22, 2021 at 02:15:31AM +0200, Simon Richter wrote:
>
> The latter is what brought us into a situation where it is no longer safe to
> move files between packages and between aliased directories in the same
> upgrade, and because users will be expected to upgrade in a single step
>
Hi,
On 21.08.21 19:47, Luca Boccassi wrote:
By all means, go and fix it, make it a top priority for dpkg to sort
out, all hands on deck, whatever needed - but to demand the entire
project has to stand still, and to de-facto derail the effort put in to
catch up with the rest of the world by
On Fri, 2021-08-20 at 07:56:33 -0600, Sam Hartman wrote:
> > "Theodore" == Theodore Ts'o writes:
> Theodore> FWIW, from following the discussion, I've become more and
> Theodore> more convinced that a symlink farm is *not* the right
> Theodore> answer, regardless of whether it is
On Sat, 2021-08-21 at 18:47:50 +0100, Luca Boccassi wrote:
> My recollection (which might be wrong, but a quick look at release
> notes seems to support it with 11.04 having multiarch 2 years before
> Wheezy) is that Canonical led the way with the multiarch effort in
> Ubuntu, and Debian followed
On Sat, Aug 21, 2021 at 06:47:50PM +0100, Luca Boccassi wrote:
> My recollection (which might be wrong, but a quick look at release
> notes seems to support it with 11.04 having multiarch 2 years before
> Wheezy) is that Canonical led the way with the multiarch effort in
> Ubuntu, and Debian
On Sat, 2021-08-21 at 16:20 +0200, Wouter Verhelst wrote:
> On Sat, Aug 21, 2021 at 02:40:02PM +0100, Luca Boccassi wrote:
> > On Sat, 2021-08-21 at 10:26 +0200, Wouter Verhelst wrote:
> > > It bothers me that you believe "we've been doing this for a while
> > > and it didn't cause any problems,
On Sat, Aug 21, 2021 at 10:26:13AM +0200, Wouter Verhelst wrote:
> It bothers me that you believe "we've been doing this for a while and it
> didn't cause any problems, so let's just continue doing things that way
> even if the people who actually wrote the damn code say that path is
> littered
On Sat, Aug 21, 2021 at 02:40:02PM +0100, Luca Boccassi wrote:
> On Sat, 2021-08-21 at 10:26 +0200, Wouter Verhelst wrote:
> > It bothers me that you believe "we've been doing this for a while
> > and it didn't cause any problems, so let's just continue doing
> > things that way even if the people
On Sat, 2021-08-21 at 10:26 +0200, Wouter Verhelst wrote:
> On Fri, Aug 20, 2021 at 11:21:55AM +0100, Luca Boccassi wrote:
> > On Thu, 2021-08-19 at 19:55 -0400, Theodore Ts'o wrote:
> > > On Thu, Aug 19, 2021 at 10:39:45PM +0200, Simon Richter wrote:
> > > >
> > > > I think no one likes that
On Fri, 2021-08-20 at 23:15 +0200, Simon Richter wrote:
> Hi,
>
> On 8/20/21 3:56 PM, Sam Hartman wrote:
>
> > Simon's position seemed to be that we need a dpkg update in order
> > to
> > move forward and that we cannot depend on that mid-release.
>
> Yes, except if we give up "apt
On Fri, Aug 20, 2021 at 11:21:55AM +0100, Luca Boccassi wrote:
> On Thu, 2021-08-19 at 19:55 -0400, Theodore Ts'o wrote:
> > On Thu, Aug 19, 2021 at 10:39:45PM +0200, Simon Richter wrote:
> > >
> > > I think no one likes that idea, but it's the only solution that doesn't
> > > immediately fail
Hi,
On 8/20/21 3:56 PM, Sam Hartman wrote:
Simon's position seemed to be that we need a dpkg update in order to
move forward and that we cannot depend on that mid-release.
Yes, except if we give up "apt dist-upgrade" as the interface for the
upgrade to the next stable release.
I can see
On Fri, Aug 20, 2021 at 07:56:33AM -0600, Sam Hartman wrote:
> As you know, one of the ways we can see how close we are on consensus
> is to look at what happens when someone proposes a summary like you did.
Thanks, that was my goal: trying to see if we could move the
discussion towards some
> "Theodore" == Theodore Ts'o writes:
Theodore> On Thu, Aug 19, 2021 at 11:17:17AM +0100, Simon McVittie wrote:
>> In this specific case, I think the thing you're having a problem
>> with is the gradual, file-by-file migration of executables into
>> /usr by individual
Luca Boccassi writes:
> On Thu, 2021-08-19 at 19:55 -0400, Theodore Ts'o wrote:
>> On Thu, Aug 19, 2021 at 10:39:45PM +0200, Simon Richter wrote:
>> >
>> > I think no one likes that idea, but it's the only solution that doesn't
>> > immediately fail because it requires a dpkg update that hasn't
On Thu, 2021-08-19 at 19:55 -0400, Theodore Ts'o wrote:
> On Thu, Aug 19, 2021 at 10:39:45PM +0200, Simon Richter wrote:
> >
> > I think no one likes that idea, but it's the only solution that doesn't
> > immediately fail because it requires a dpkg update that hasn't shipped with
> > the current
On Fri, 20 Aug 2021 at 09:56, Theodore Ts'o wrote:
> P.S. I had a vague memory that there was some update in the long
> distant past where we did require a manual upgrade of dpkg first. Or
> is my memory playing tricks on me? I do know that a manual update of
> dpkg is the first step in a
On Thu, Aug 19, 2021 at 10:39:45PM +0200, Simon Richter wrote:
>
> I think no one likes that idea, but it's the only solution that doesn't
> immediately fail because it requires a dpkg update that hasn't shipped with
> the current stable release, breaks local packages (kernel modules, firmware,
>
Hi,
On 8/19/21 4:45 PM, Theodore Ts'o wrote:
FWIW, from following the discussion, I've become more and more
convinced that a symlink farm is *not* the right answer, regardless of
whether it is done centrally or via individual packages moving files
and created symlinks if necessary in
On Thu, Aug 19, 2021 at 11:17:17AM +0100, Simon McVittie wrote:
> In this specific case, I think the thing you're having a problem with is
> the gradual, file-by-file migration of executables into /usr by individual
> packages and individual packages' maintainers. That's not merged-/usr:
>
On Thu, 19 Aug 2021 at 10:06:27 +0200, Helmut Grohne wrote:
> You keep proposing adding /bin/foo -> /usr/bin/foo symbolic links via
> maintainer scripts.
I'm not proposing this! I'm trying to *not* need to do that in any more
packages, and instead do usrmerge or equivalent, so that individual
74 matches
Mail list logo
