[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: merged /usr vs. symlink farms



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 facade.
> 
> > Precisely - and the correct technical question is, how many bug reports
> > were opened by users?
> 
> That is the majority vote by people who do not look behind the facade.

A vote is a conscious decision and arbitrary act. Your system breaking
is not.

> > Strawmen can always be constructed, for example
> > you can completely brick a system by running 'apt install bash:armhf'
> > but that doesn't mean multiarch should be scrapped and reverted, it
> > would be silly to suggest that - and yet here we are.
> 
> This is precisely the debate we would be having if there was a package 
> that enables armhf as a foreign architecture whenever it is installed: 
> it would not break systems on its own, but we'd have to be a lot more 
> careful in other packages about expressing dependencies.
> 
> I have armhf enabled on my laptop, and the resolver has suggested 
> replacing bash:amd64 with bash:armhf a few times -- but I know that my 
> setup is unusual.

It's exactly the same. This dpkg bug manifests itself via a carefully
crafted sequence of package upgrades/downgrades with a specific set of
metadata between them. If I uploaded a new version of iproute2 which
enabled armhf and installed bash:armhf the suggestion wouldn't be to
revert the debian multiarch implementation.

> > Conversely this
> > doesn't mean the dpkg database bug shouldn't be fixed,
> 
> Keep in mind that this isn't a dpkg bug, because dpkg never created a 
> filesystem layout that was inconsistent with its database; usrmerge did.
> 
> What we are talking about is adding a workaround for the usrmerge 
> package to dpkg, and how to make sure that it works, regardless of 
> whether the system has already been converted or not, if it has, which 
> version of usrmerge was used, whether the package is currently installed 
> or not, whether it will be installed as part of an upgrade and if so, 
> which state the dpkg package is in at the time it is installed.
> 
> For example, a possible scenario could be that the system was converted 
> with usrmerge version 9 (which modified dpkg.cfg), then the usrmerge 
> package was deinstalled as a later version declared a conflict that the 
> user resolved in favour of the other package, usrmerge hasn't been 
> installed since, then during the upgrade to bookworm, a new version of 
> dpkg is unpacked (but not configured yet), then a new version of 
> usrmerge is unpacked, and then dpkg --configure -a is run.
> 
> So we need a list of things that need to happen to get back into a 
> consistent state and a way of sequencing that inside the package 
> dependency DAG.

This is 100% a dpkg bug. rpm doesn't have it. Other package managers
don't have it. And it's fine - all software has bugs.

> > so that the
> > replace+move bug can't happen in the future, but it simply makes
> > overblown and hyperbolic ideas such as "all systems are broken, revert
> > everything" and "let's cancel the TC decision" appear counter-
> > productive and deeply unhelpful toward finding an actual, realistic
> > solution.
> 
> The TC decision does not specify technical details, which was a grave 
> mistake because the implementation was so shoddy that I doubt the TC 
> would have signed off on that, had they been consulted on the details.

You are missing a gigantic 'IMHO'. For me the implementation was great
- simple, to the point, matching other distros so that we don't get
yet-another-incompatibility for the sake of being 'special', and
working just fine across millions of installations for 2+ years and
counting with hardly a hiccup. Of course it has bugs, because it's
software, or more precisely yet it makes old bugs in other packages
(dpkg) come to light, which happens and it's not the end of the world -
we'll fix them or work around them, like the tens of thousands of other
bugs affecting debian. Also, from what we have heard "unofficially"
here and elsewhere, it appears that the TC has always indeed preferred
the current approach of matching other distros and symlinking the top
dirs, rather than the objectively failed symlinks farm approach.

> Pretty much no one is interested in rolling this back, but a lot of 
> people, me included, are indifferent and cannot see the benefits, 
> especially as they consist mainly of things that used to work in the 
> past, were broken during the systemd rollout and subsequently declared 
> out of scope when people complained, so all users of these features have 
> already left anyway.
> 
> An actual, realistic solution will work for all users, including those 
> who have now installed or upgraded to buster from DVD, run offline and 
> will upgrade to bookworm from DVD when it comes out.

You say that, and yet just a few hours ago this was posted:
https://lists.debian.org/debian-devel/2021/08/msg00490.html
What is that if not a request to revert the TC decision and rollback? I
mean it could hardly be more explicit than that.

> > Given this and the last few mails, it seems to me at this point the
> > only possible way forward is what Timo and Ted suggested the other day,
> > namely to have an external tool, possibly part of src:usrmerge, scan
> > the dpkg database and fix it? Possibly on a trigger?
> 
> No. We couldn't sequence that correctly, we'd have to somehow make 
> installation of the usrmerge package mandatory, and that tool would need 
> to touch the dpkg database at a point where dpkg is active in the 
> background.
> 
> 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 -- luckily, 
> these should be really rare) and then leave a consistent state again 
> that allows package maintainers to use all dpkg features again after the 
> bookworm release.

It might make more sense from the technical perspective, but it's
glaringly obvious that from the social perspective that it's not going
to happen, so I don't see how it's worth anyone's time to speculate
over it, rather than how to make the realistic alternative work
reasonably well.

-- 
Kind regards,
Luca Boccassi

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: