Losses at Mandriva [LWN.net]

Losses at Mandriva

Posted Dec 2, 2008 20:52 UTC (Tue) by MattPerry (guest, #46341)
In reply to: Losses at Mandriva by AdamW
Parent article: Losses at Mandriva

> Actually, I can give you an equally flippant but more true reply.

I'm both saddened and disappointed that you feel my question was flippant. I posed that question as a serious inquiry into the current state of affairs of software distribution for Linux-based system. I'm not a programmer or developer; I'm only an end user. As an end user I am unhappy with the current state of Linux distributions.

As it stand now, users are held hostage by their distributions and lose choice and control. A non-technical user must use whatever packages are supplied by the distribution. If they upgrade their distribution then all of the applications, not just the core operating system, upgrade as well whether they want that to happen or not.

Are there ways to avoid this? Yes, a user could compile the package from source and install and maintain it that way. But that requires a certain level of technical sophistication and knowledge that the average computer user may not have nor care to develop. Even I, as a system administrator, tire of such detailed management on my home computers. A non-technical user would certainly be held hostage to whatever revisions of software ship with the distribution.

> If there were One True Opensync Package, who gets to maintain it, me or
> the Fedora guy?

Neither. The Opensync maintainers should maintain the package. The package repository should added as another entry into the distribution's repository list, or else someone could download the package and double-click to install the package.

I feel this way about all non-core OS packages, which would include all end user applications like browsers, office apps, media players, CD burning software, etc. There would potentially be thousands of repositories listed in one's apt or yum sources list rather than just one or two.

> And which version does it get to be?

It shouldn't matter as long as the packages of the older version were around and were compliant with whatever LSB revision your operating system supports. That way you can install whatever version works for you, even if it's an older version. End-users could run older software that is compatible with their system, no matter what reason they may choose to do so.

(Log in to post comments)

Losses at Mandriva

Posted Dec 2, 2008 21:25 UTC (Tue) by jspaleta (subscriber, #50639) [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.

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

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.

Losses at Mandriva

Posted Dec 3, 2008 4:36 UTC (Wed) by jamesh (subscriber, #1159) [Link]

What do you do when the upstream package maintainer doesn't want to maintain the package for you?

In the situation Adam mentioned, Fedora was using an older OpenSync package in order to work with another package they are distributing. Could they really expect the upstream maintainer to provide an up to date package for software they consider obsolete? How about handling security issues?

Now consider the other packages that might rely on OpenSync. Lets say that they produce different binaries when compiled against the different versions of OpenSync. Should the distribution expect all these upstream package maintainers to produce a second version of their package?

These are the sort of integration problems distribution packagers face all the time, and it doesn't seem sensible to expect unaffiliated package maintainers to place the same importance on the problems.

Things are a bit simpler at the application layer, where upgrades won't break other parts of the distro. It isn't always simple though, with applications like Firefox providing components that get reused by other packages.

Losses at Mandriva

Posted Dec 4, 2008 18:59 UTC (Thu) by AdamW (guest, #48457) [Link]

Just to note, you inverted the example. I use opensync 0.22 in Mandriva because it's the stable release that works and I actually *test* that stuff. 0.3 is the current entirely unstable development branch that cannot do anything useful and frequently eats people's data. However, several distributions (including Fedora) didn't bother to read the big DON'T USE 0.3! warning at www.opensync.org and packaged 0.3 anyway. And, consequently, their packages are utterly useless.

Losses at Mandriva

Posted Dec 4, 2008 19:05 UTC (Thu) by AdamW (guest, #48457) [Link]

As others have noted, it was my first reply I considered flippant, not your question. :)

In general I would agree with jspaleta's reply. I think the likelihood of anyone believing that a world where developers maintained all the packages would be a good one has a directly inverse relationship to the number of packages that person maintains. =)

I am currently working on migrating Mandriva's development branch from Tcl/Tk 8.5 to Tcl/Tk 8.6. This involves updating a bunch of rather obscure applications that use Tcl.

When you do this kind of thing on a regular basis you get a deep and meaningful understanding of just *how* crack-addled a set of build scripts a really determined developer can write, when they set their minds to it. It's not pretty.

OK, yes, I could carefully re-implement all these build scripts in autotools or cmake or something so that they will work across all distributions and Solaris and contribute them back to upstream. Hell, I probably should. If the build script is mostly sane, I fix it and send the patch. But if it's a gigantic ball of pain, I just hack it up so it works for building a Mandriva package (but would not work at all on any other distro or if you were building from source), and move on. Because it needs to get done, and if I spent all my time re-writing shit build scripts I'd never actually get the original task (migrate to Tcl 8.6) done.

Plus, half of these projects have been dead for years. But we still need the app, because someone out there still uses it, and no-one ever bothered to write a modern replacement because the old thing still more or less works. So where would I send the fix?

Basically, when the happy-clappy "let's have one awesome universal package base!" theory runs into the mundane reality of developers who have no clue how to install things properly and years-dead projects, it dies in a hurry.