On Wed, 30 Aug 2023 at 12:57, Ian Jackson
wrote:
>
> On the burden of proof and the correctness of software:
>
> I'm afraid I see a pattern, where blanket statements are made which
> are only "mostly" or "roughly" or "generally" true. But the
> discrepancies and details matter. When we make computer systems, it's
> not good enough to if they're only "mostly" right.
>
> Every program is an unproven conjecture whose truth we end up relying
> on. We need simple axioms, and rigorously correct reasoning.
Yes, and fact-free and evidence-free threads such as #1050001 go in
the exact opposite direction.
> Aliased usrmerge, when deployed, was a conjecture that was disputed:
> "usrmerge via directory aliasing functions correctly".
And it demonstrably does: it works beautifully and flawlessly on an
uncountable number of Debian, Ubuntu, Mint, Fedora, RHEL, CentOS,
Arch, SUSE, Yocto, Gentoo, etc. installations, for a decade in some of
those cases.
> Helmut Grohne writes ("Bug#1050001: Unwinding directory aliasing [and 3 more
> messages]"):
> > In order to prefer Debian over something else, we want it to be similar
> > enough to make switching feasible while making it differ from others
> > enough to make switching worthwhile. Not having aliasing symlinks hardly
> > seems like an aspect that makes Debian more suitable to people. I guess
> > that you disagree with this and that is fine.
>
> Debian has historically been simply much more reliable. That
> reliability doesn't come from one particular decision. It comes from
> an aggregate of, on the whole, making better decisions. That
> reliability is very valuable to our users and downstreams. It's
> one of our our most compelling advantages.
It comes in the largest part from having reliable upstreams that can
use common, stable, reliable and proven interfaces, such as the
usr-merged filesystem layout which has been the de-facto standard
across the vast majority of Linux distros for the past decade.
> > My impression has always been that the disagreement on the end
> > state was involving a minority.
>
> Well, if you disagree with aliased usrmerge and say you don't want it,
> you get abuse. Even here, many abusive messages have been posted with
> impunity by persons with considerable status.
Sure, insofar as asking for evidence for outrageous and unproven
claims can be considered 'abuse'
> > > This argument is basically drawing together the common factor in the
> > > DEP-17 problem list.
> >
> > And that's precisely why I don't understand your argument. All of the
> > DEP-17 problems are supposed to go away. So it appears as if you cite a
> > list of problems that I expect to not be problems for much longer as a
> > reason for changing the end goal.
>
> DEP-17's list of *problems* forms a category: directory-aliasing-
> induced malfunctions. But the DEP-17 *solutions* are ad-hoc, and many
> are only applicable to to malfunctions that occur during migration.
No, it's a list of potential bugs caused by dpkg being hopelessly
broken, and effective and demonstrably correct temporary workarounds
for them.
> > > Affected tooling includes not just our .debs, but also remote
> > > configuration management systems like Ansible, image construction
> > > (Dockerfiles), and 3rd-party software installation progrmas (including
> > > both 3rd-party .debs and 3rd-party script-based installation systems).
> >
> > I don't follow the reasoning. [...]
>
> Sam has posted a helpful set of examples of things that one might do,
> whose consequences with aliased directories are unclear.
>
> These are of course only examples.
Yes, they are only examples, more specifically evidence-free examples.
It would be trivial to demonstrate that Ansible/Puppet/whatever are
broken and don't work on Debian/Ubuntu/Fedora/RHEL/CentOS/Arch/etc,
but somehow evidence remains scarce. I wonder why.
> > > I would be much more convinced that all of this isn't a problem, if
> > > there existed, and had been formally adopted (eg by existing in some
> > > manual somewhere) a short and clear set of rules about what is and
> > > isn't allowed - not just rules for us within Debian, but rules for
> > > everyone, everywhere, referring to and modifying files.
> >
> > It appears to me that the empty set of rules (outside packaging) is too
> > simple for you to consider.
>
> "Packaging" is doing a lot of work there. I find your comment rather
> tendentious, I'm afraid.
>
> I think we need a short and clear set of rules for what you can do
> with ansible, rsync, docker, etc. etc. etc., as well as just apt and
> dpkg.
Again, the rule is simple and short: vendor files go under /usr,
ignore legacy locations. Doesn't get any easier than that.
> > > > We already have the Debian Usr Merge Analysis Tool available at
> > > > https://salsa.debian.org/helmutg/dumat and its output at
> > > > https://subdivi.de/~helmut/dumat.yaml. As explained on d-d@l.d.o, I want
> > > > to turn those findings into automatic RC
