On Sat, 15 Aug 2015 20:19:03 +0000
Stephanie Daugherty <sdaugherty@???> wrote:

Hi, Stephanie! =)

> They did, but out of all this design by committee, hidden between all
> the political bullshit and bikeshedding, they also created the most
> brilliant, most comprehensive set of standards for quality control,
> package uniformity, license auditing, and of course. the most robust
> dependency management, at least among binary distributions.

Sorry, I can't agree. =(

After using a number of distributions over about 20 years, I find Debian
to be more or less average. Debian passes into stable roughly the same
number of bugs that most of the other major distributions do. This is
not to say that Debian does not make an effort. Far from it. I'm
simply saying that when you take the top ten binary Linux
distributions, they pretty much all have the same or similar issues.

>
> More importantly than that, they backed these standards up with
> automated tools that are nearly as robust as the standards
> themselves.

I agree their tools are decent - most of the time, but the tools are
really only useful for their particular use case. In my opinion, Debian
packaging was the best - 15 years ago - but after that initial work was
done, they stopped doing anything significant at all. I'm not saying
Debian packaging is bad. I find it very good, but it also have
serious limitations that should have been dealt with long ago.

Their tools work 90% of the time when you confine yourself within the
Debian stable repository. Debian packaging is extremely dependent on
versioning in their build process. It is unable to use anything other
than the last version. There are no rollbacks or test staging before
final install, for example. There is no standard mechanism to allow
for multiple libraries and precedence. Individual install scripts
should have been replaced with a Debian standard for a simple tokenized
installer so that there are no individualized shell scripts in the
packages to begin with.

The lack of the last two: multiple versions and shell scripts are why
Debian derivatives cannot share packages, even though they use
identical base code. It is also the source of the init scripts that
caused at least 70% of the reason that Devuan split from Debian in
the first place.

What I am saying is that Debian could have raised the bar long ago, but
frankly, no one cares. (It's one of the reasons I am fed up with binary
Linux versions. If it was not for lack of time, I would not be using
them at all.)

> You don't see packages interfering with one another very
> often in the Debian world, because this is caught right away by
> scripts that check that every file installed by a package, or
> automatically created by that package belongs to EXACTLY ONE package,
> otherwise all the packages have to use some approved mechanism to
> cooperate. You also see this effort it in difficult to configure
> packages that set themselves up and work out of the box, and in the
> modularized configuration that's common to many packages.

Yes and no. I've seen plenty of packages break as soon as you use
something that the majority does not. I've also seen more than few
packages that require significant intervention to work properly. That
has lessened the last few releases, but the spectre is always there.


Take care!
T.J.