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
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 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
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
> "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
> "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 cou
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 /usr/pat
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 a
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 upgra
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 cod
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
> > fi
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 and
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 o
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 10.1
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
> > upgr
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 i
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 da
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 l
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 co
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
> betw
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 impo
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 d
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 w
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 follow
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, so
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 wit
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 idea
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 dist-upgrade
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 bec
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 kind
> "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 packages
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 s
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 cros
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 individual
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:
> merged-/
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
pack
74 matches
Mail list logo
