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 if you go and tell them "ah the
> > > real
> > > problems you point out are irrelevant" then You! Are! Doing! It!
> > > Wrong!
> >
> > Again, if the magnitude of this dpkg bug was really that serious
> > there
> > would be visible consequences after almost 3 years of deployments
> > across two distributions with who knows how many million instances,
> > and
> > yet "having to run dpkg -S again" is all we can see. Where are the
> > bug
> > reports? Where are the enraged users with unusable broken system
> > and
> > lost data? Where are the reports of Canonical going out of business
> > because Ubuntu is unusable?
>
> 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 "opinion"). I'd expect the problems with
> aliased directories to be that kind of insidious issue that people
> have a very hard time trying to pin point, and which will be getting
> worse as time passes.
If I understand correctly, what has been stated as a potential
theoretical consequence is files disappearing and upgrades failing. Why
would these be hard to detect? It would seem to be a pretty visible
consequence, no?
> > The bug is real, nobody doubts that - it has been filed on dpkg 20
> > years ago.
>
> You keep repeating this, but I have no idea what bug you refer to.
>
> There's #148258 (from 2002), which is conffile related, and not
> actionable and should probably just be closed.
>
> There's #182747 (from 2003), which while apparently similar is
> something else completely. This is about the (IMO) misfeature of
> supporting a local admin to redirect (not alias) a directory using a
> local symlink (mainly for space management reasons). For an
> explanation
> see <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779060#10>.
>
> There's #406715 (from 2007) which is related to the above misfeature.
I am referring to #134758 since it's linked as the root cause from
usrmerge's #848622.
"dpkg-query: Make -S handle unowned symlinks resolving to owned
pathnames" filed in February 2002 - 19 years and a half ago. I refer to
that because it's linked as the root cause in the BTS of the relevant
issue with usrmerge we are discussing.
> > What I am taking issues with is the representation of its
> > actual, real effects, and thus its severity and the consequences
> > for
> > the project. There are a lot of words being spent on how terrible
> > and
> > broken and unacceptable the status quo is, and yet not a single
> > link
> > to a bug report.
>
> What I'm appalled at is the sloppiness and dogma shown in the name of
> a filesystem layout that will have very minimal benefit for final
> users
> (in contrast to some use cases for some admins or installations that
> should already know what they are doing, and can manage all potential
> downsides in a controlled way through a hack like usrmerge),
> knowingly
> in detriment of robustness and stability.
**in your opinion** it will have minimal benefits. It is a legitimate
opinion, but still an opinion with which others disagree. Seeing how
every popular distro has moved or is moving, general consensus appear
to be going in the other direction. On the other hand, robustness and
stability are measurable: number of crashes, number of lost systems,
number of systems with lost data. The total count in the past 3 years
where it has been default in Debian and Ubuntu puts the grand total of
reports of crashes, lost systems and lost data at zero. So again, the
evidence that this change decreases stability is nowhere to be seen.
> > By all means, go and fix it, make it a top priority for dpkg to
> > sort
> > out, all hands on deck, whatever needed -
>
> To even consider the possibility to support this missing feature in
> dpkg would require for it to get support for at least tracking
> filesystem metadata (which is has *never* *ever* supported), which is
> currently not deployable:
>
> <https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking>
>
> Even with that support in place, that just would not give automatic
> aliased directory support. It would need no package to ship anything
> inside those directories, and it would also need for some package to
> ship those aliased symlinks. And then many corner cases would need to
> be considered as then dpkg will need to reconcile what's on the
> filesystem, on its database and on the various .deb (given that these
> have been a shared resource, that it cannot possibly and safely
> switch
> type by itself), w/o also breaking previous expectations. Not to
> mention
> that the general aliasing issues still would not disappear.
I make no claim whatsoever on whether it would be easy, simple or
anything else. Others have proposed solutions, I have not commented on
them nor intend to.
> > but to demand the entire project has to stand still,
>
> So wait, when it suits you the "entire project" is involved and
> cannot
> do stuff, but when it does not the "entire project" is not required
> to
> do anything because the proposed solution magically solves stuff for
> free with no effort involved… right.
It doesn't suit "me" - it "suits" the unanimous decision of the
Technical Committee.
> > and to de-facto derail the effort put in to catch up with the rest
> > of the world
>
> This again. The rest of the world is not Debian, and as Wouter nicely
> put it, we used distinguish ourselves for doing things right. Also
> while
> I'm for merging into /usr, selling it as some kind of technological
> advancement breakthrough sounds rather ridiculous. But I guess times
> change, and "transitions" now are not planned nor thought nor
> designed
> and people just throw stuff to the wall and just check whether it
> sticks or not…
Nobody is selling this as a breakthrough, it was never claimed to be, I
don't see how such hyperboles help anybody. Quite the opposite, while
ten years ago it might have been a nice idea to simplify things
considerably, today is just a boring standard behaviour in most places
- nothing extraordinary about it. It is relevant for its absence, if
anything, as it pushes upstreams to keep legacy stuff around, which is
getting tiresome.
> > by imposing an unworkable, demonstrably failed solution (symlinks
> > farm)
>
> So you keep claiming…
It is not a claim, it's an observation. A distro with much better tools
and a very strong governance model tried it and failed for reasons
explained a million times already (and always invariably ignored by you
and a few others). That's solid, hard evidence.
> > to work around a dpkg bug instead of fixing it internally,
>
> …
>
> > to me does not seem acceptable in any
> > way, shape or form without some real, serious evidence that the sky
> > has
> > indeed fallen.
>
> If that's an approach to reliable and stable systems where that's
> the binary "the sky has fallen" or not, I supposed it follows that
> in that world view stuff like security is handled such that an
> analysis ("opinion", sorry) of a vulnerability can be downplayed
> and ignored because there are no reported botnets riding on.
>
> I guess I might be old fashioned or something, but I'm not interested
> at all in sharing such world.
>
> Unimpressed,
> Guillem
No, it doesn't follow as that at all, this is a strawman of your own
creation - as it turns out, different things might be different and be
handled differently. I must say statements like this makes the "assume
good faith" principle incredibly hard to follow. One states that
despite widespread, default usage across multiple distros for years
there's no evidence of unrecoverable failures, and instead of providing
evidence of the contrary or explanations for the absence of such
evidence, the answer is "oh well I guess you ignore security
vulnerabilities then"? How is this a constructive answer?
--
Kind regards,
Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part