| |||||||||||||
|
| |||||||||||||
Losses at MandrivaLosses at MandrivaPosted Dec 2, 2008 21:25 UTC (Tue) by jspaleta (subscriber, #50639)In reply to: Losses at Mandriva by MattPerry Parent article: Losses at Mandriva
I think you underestimate the number of build time choices that application developers force people to make. And I think you grossly over-estimate the level of detail the LSB actually covers.
Not everything is a runtime discoverable option. Some options can only be chosen at build time. Those options pull in other libraries as dependencies...libraries with version specific API's and ABI's. Holding onto all possible versions of all possible libraries to try to satisfy thousands of individual application repositories is a maintenance and security nightmare.
-jef"cringes at the though of thousands of individual python based applications running their own repositories...and having users trying to rely on the fragility of that arrangement across a python version jump in a distribution"spaleta
(Log in to post comments)
Losses at Mandriva Posted Dec 3, 2008 2:45 UTC (Wed) by madscientist (subscriber, #16861) [Link]
Not only that, but libraries are actually the easiest problem to solve. Yes, obviously you can always just install enough versions so everything can start properly with its preferred version.
But, on a modern system the most interesting and difficult interaction is at runtime, as various programs talk to each other, through dbus or pipes or sockets or whatever. Trying to keep all that messaging 100% backward compatible is a nightmare and there's no simple solution to this problem: newer applications expect the services they interact with to have newer features: that's why we upgrade, after all. That's why you generally need to upgrade the entire desktop environment, because those applications and applets are strongly linked.
And, although maybe it's appropriate for LWN, you are completely ignoring the large number of non-Linux platforms that most upstream developers support. Requiring upstream developers to be fluent in not just RPM vs. DEB, Red Hat vs. OpenSUSE vs. Fedora vs. Gentoo ebuilds vs. Ubuntu vs. Slackware vs. PackageKit, but to ALSO understand FreeBSD ports and the differences building packages for the *BSDs, Solaris, HP-UX, AIX, etc. is completely infeasible. And upstream developers are simply not willing to compromise the software in Linux-specific ways, the way package maintainers often need or want to. That's no one's fault: it's the result of perfectly legitimate differences in focus and priorities.
As an end-user I'm sure it seems like a lot of wasted effort. But believe me, if you were involved in the guts of these efforts, whether on the package maintainer side or the upstream developer side, you would (modulo the inevitable conflicts that always arise) agree that there's no really practical alternative and there are even advantages to doing things this way.
ObDisclosure: I'm an upstream developer for a common software package.
Losses at Mandriva Posted Dec 3, 2008 22:15 UTC (Wed) by louie (subscriber, #3285) [Link] I think you underestimate the number of build time choices that application developers force people to make.That sounds like a problem to fix, not a problem to work around. It's not like these upstreams are proprietary. If opensync 0.3 is broken, that indicates the people doing packaging downstream should have been spending their time doing QA upstream. Ditto for KDE4's dependencies, python's upgrades, etc. What you're saying is 'upstream is stupid, so we have to spend thousands of man-hours... not fixing upstream.' (And yes, I have thousands of hours of experience doing both upstream and distro-level work, and like walters, I agree that the best option is always doing work upstream. The current arrangement is maddeningly wasteful and shouldn't be necessary for any but the most core packages.)
Losses at Mandriva Posted Dec 3, 2008 23:00 UTC (Wed) by jspaleta (subscriber, #50639) [Link]
All compile time choices are a QA issue? Hmm that's an interesting stance to take. I wouldn't go that far. Making some dependencies optional at compile time can be a deliberate design choice.
Are you saying that all optional functionality across all applications and projects which relies on external libraries should be coded as runtime detectable features and that compile-time linkages to optional libraries should be forbidden on the grounds of QA?
-jef
Losses at Mandriva Posted Dec 5, 2008 4:40 UTC (Fri) by MattPerry (guest, #46341) [Link]
> I think you underestimate the number of build time choices that
> application developers force people to make. And I think you grossly > over-estimate the level of detail the LSB actually covers.
I imagine you are correct on both counts. I just see it being done successfully with Wine and imagine it could be done with other software as well. I hope there would be a way to provide what I want at some point in the future, at least for desktop applications.
|
|
||||||||||||