On Sat, 15 Aug 2015 20:19:03 +0000 Stephanie Daugherty <[email protected]> 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. _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
