Roland Mas wrote:
Despite my previous emails, I have to side with Richard here. What you call “dogma” is actually considered “best practices” in the distribution world, and it's *based on* practicality and experience.
In this case it is demonstrably impractical. There is simply no point in distributing code that has been broken in the attempt to remove "duplicate" libraries. Stuff that actually works beats "philosophically nice but not working" every time. If you can't see the stupidity of what's been happening, you really need to take a big step backwards, and have a think about priorities.
Embedded copies of libraries are an extra burden for distributors because of the combinatorics involved when one of these libraries needs to be updated for whatever reason (security update, porting to a new architecture, porting to a new version of a compiler, porting to an entirely different compiler, and so on). Shared libraries actually help maintain a working system with a reasonable amount of work, and that's a practical advantage. The same applies for the build system: many people dislike autotools, but many people understand it, which means that maintenance work isn't restricted to a few gurus.
So what ? What's the point of removing a duplication that isn't a duplication - it's actually different, and that difference is crucial to the correct operation of the software. [And if you do substitute one library for another, and aren't 100.00000% sure that they are exactly the same, then you'd better bloody well be prepared to test the resulting code at least as well as I do - that means going through all the color instruments and checking they all work, as well as any other functionality that could be affected. If you're not prepared to do that THEN DON'T CHANGE IT.]
It does push some more work upstream, of course (pushing for integration of your patches into the libraries you forked), but it actually provides practical benefits: distributors can focus on their integration work, upstream authors can focus on their project (where they're most competent), the same applies for authors of libraries, and in the end users get up-to-date software on their distribution. Pointing the users to your site is good for some users, but not everyone wants to grab and compile stuff themselves. On the other hand, there's machinery in the distribution that can go “Hey, it seems you have a colorimeter plugged into this computer, shall I install Argyll for you?” and the user gets it all working in a matter of seconds (that's called discover-pkginstall in Debian, something similar probably exists for other distros). Making it easier for the distro to ship an Argyll that's as close to the original as possible is good for everyone.
It's no good for anybody when what's being distributed is broken. And I'm not going to be held to ransom by any upstream libraries accepting or not, essential changes to make it work for my application, or officially releasing them in a timely manner (that is the whole _point_ of open source, after all - I have the freedom to fix things! I'm certainly not going to let some random Linux distribution try to take that freedom away from me!) Linux distributions haven't earned any special treatment from me - my aim is strictly to release cutting edge, _working_, cross platform color software. Graeme Gill.