| |||||||||||||
|
| |||||||||||||
Losses at MandrivaLosses at MandrivaPosted Dec 2, 2008 18:43 UTC (Tue) by AdamW (guest, #48457)In reply to: Losses at Mandriva by MattPerry Parent article: Losses at Mandriva
"Why aren't we at the point where there can be one or two packages (to accommodate rpm and deb) that can be installed on any LSB compliant distro?"
Actually, I can give you an equally flippant but more true reply. Packages *are* distributions. This is the same question as "why do we have different distributions?" - because people want different distributions.
To take a random example, I maintain opensync for Mandriva. I use version 0.22, because it actually freaking works. Fedora has 0.3, because it's a bigger number and KDE 4 expects it to be there (never mind that KDE 4 cannot do anything at all useful with opensync).
If there were One True Opensync Package, who gets to maintain it, me or the Fedora guy? And which version does it get to be?
Sure, because I'm right and he's wrong, we can resolve that one (it would be 0.22 and he would be demoted and punished with a week's worth of bug triage work). But imagine that....TIMES TWENTY THOUSAND (deep booming movie announcer voice). That's how many little ego conflicts you'd have to resolve to have a single bunch of packages every distro would use. It's never going to happen. It'd be like herding several thousands cats and several thousand skunks, all at once.
(Log in to post comments)
Losses at Mandriva Posted Dec 2, 2008 18:51 UTC (Tue) by avik (subscriber, #704) [Link] If there were One True Opensync Package, who gets to maintain it, me or the Fedora guy? The opensync maintainer.
Losses at Mandriva Posted Dec 2, 2008 19:25 UTC (Tue) by AdamW (guest, #48457) [Link]
As a general rule, developers are *crap* at being package maintainers. This is why we have package maintainers. :)
Or were you replying in a fashion as flippant as my own? If so, good job =)
Losses at Mandriva Posted Dec 2, 2008 20:07 UTC (Tue) by avik (subscriber, #704) [Link]
Only partially. I generally cringe at the duplication of effort involved in maintaining a distro.
Packaging support should be part of the tarball and worked up upstream, instead of being duplicated in every distribution. Many packages do come with rpm spec files (or the deb equivalent).
Losses at Mandriva Posted Dec 2, 2008 20:11 UTC (Tue) by AdamW (guest, #48457) [Link]
...which, as I mentioned, are generally...not good. Anyway, as I said, it's still too glib an answer. Different distributions package things differently; that's the basic raison d'etre of distributions. Then each distribution has a user base who supports that distribution's way of doing things.
To take another example. Say an app has an optional dependency on a certain library. On the one hand, if you build against that library, you get a cool feature - but if you don't, you save the requirement.
A 'lean' distribution will want to not build against the library. A 'full fat' distribution will want to build against it. How do you reconcile that in the One True Package? You can't.
That's just another tiny example. The fundamental point is, multiple distributions exist because there are multiple valid perspectives on the best way to do things, which can't be adequately addressed in One True Package Set that everyone uses.
Losses at Mandriva Posted Dec 3, 2008 8:40 UTC (Wed) by avik (subscriber, #704) [Link]
Use a plugin architecture.
I agree with your point, however.
Losses at Mandriva Posted Dec 3, 2008 9:43 UTC (Wed) by jamesh (subscriber, #1159) [Link]
What do you do if the application doesn't use a plugin architecture? Do you boycott it until they rewrite things so that a single binary can fit all situations?
Losses at Mandriva Posted Dec 4, 2008 15:20 UTC (Thu) by avik (subscriber, #704) [Link]
You work with upstream to add a plugin architecture. In the same way, if there's a bug, you fix it upstream to avoid duplication of effort.
Losses at Mandriva Posted Dec 5, 2008 0:37 UTC (Fri) by nix (subscriber, #2304) [Link]
And if upstream says 'plugins? No way!' or is just impossible to work
with? (This is not academic: I can name several such projects, some of critical importance, alas)...
RPM macro set hell Posted Dec 12, 2008 15:37 UTC (Fri) by gvy (guest, #11981) [Link]
> Many packages do come with
...crap accidentally named *.spec :-[
It's fortunate if typical one loaded with mammoth's stdout like BuildRoot and %clean actually builds on say Fedora *and* openSUSE but ask packagers on RPMs with better macro set and they'll yell "CRAP!" at that.
I'm not even touching surface with stuff like control(8) which is developed and supported in Owl GNU/*/Linux and ALT Linux to let the packager limit the SUID/SGID scatter, and to let the sysadmin set up app modes in persistent manner. How can I propose to add %pre/%post scriptlets supporting that to upstream if that would blow up on mainstream cr... distros, that is?
Disclaimer: I maintain some 200+ packages in ALT Linux, most of my spec imports begin with "{,massive }spec cleanup" in %changelog (if there was any) and Fedora specs are usually last resort being usually, well, ugly :(
While at it, I'd not recommend Mandriva to anyone since "new order" fired Gael. Well, some people chose to work with them or use what they do; hope they understand before too long. Sad since there was nice feeling with a touch for details there... back in 7.x days.
Losses at Mandriva Posted Dec 2, 2008 18:56 UTC (Tue) by timschmidt (guest, #38269) [Link]
Of course it can happen... In fact, it does. It just takes a lot of time. The locals call it Debian.
Losses at Mandriva Posted Dec 2, 2008 19:26 UTC (Tue) by AdamW (guest, #48457) [Link]
Then why do so many people use Ubuntu?
Losses at Mandriva Posted Dec 2, 2008 19:42 UTC (Tue) by fabo (subscriber, #49199) [Link]
because it seems easier to use and more sexy.
Losses at Mandriva Posted Dec 3, 2008 10:36 UTC (Wed) by Los__D (subscriber, #15263) [Link] because it is easier to use and more sexy. There, fixed it for you. :p
Losses at Mandriva Posted Dec 10, 2008 20:28 UTC (Wed) by jospoortvliet (subscriber, #33164) [Link]
No, he was right, it SEEMS easier and sexier. I'm not saying it's a bad
product, but it's not especially good or anything. Of course it's hard to be objective about it, but at least I don't feel it is any better than OpenSuse or Mandriva. You'll have a hard time come up with actual *proof* that the *buntus are any better - at anything.
Sure, they make a lot of noise, but that doesn't mean they're good. They
Illusions at Ubuntu Posted Dec 12, 2008 15:40 UTC (Fri) by gvy (guest, #11981) [Link]
It might seem you fixed it but in fact you broke it. Somehow unsurprising.
Losses at Mandriva Posted Dec 2, 2008 19:49 UTC (Tue) by briangmaddox (subscriber, #39279) [Link]
Because each Debian stable release is about five years old as state of the art goes? ;)
What difference between packages Posted Dec 3, 2008 10:55 UTC (Wed) by rvfh (subscriber, #31018) [Link]
Or better: why does Ubuntu need to re-package the Debian packages? Even debianutils is re-packaged!
I know some packages do not exist in Debian in the first place... or so I was told.
What difference between packages Posted Dec 3, 2008 19:06 UTC (Wed) by fabo (subscriber, #49199) [Link]
Ubuntu doesn't re-package every Debian packages.
Many packages in Ubuntu are "pristine" Debian packages. Some packages doesn't exist in Debian in the first place but some Debian packages doesn't exist in Ubuntu too.
What difference between packages Posted Dec 3, 2008 19:48 UTC (Wed) by jspaleta (subscriber, #50639) [Link]
Have any statistics as to how many 'pristine' debian packages by Ubuntu collections?
Are they more likely to be found in Ubuntu universe versus Ubuntu main or what? Are we talking like 1% of Ubuntu's main collection? Are we talking 10% of Ubuntu's universe? Or are we just talking about a handful of pristine debian packages?
-jef
What difference between packages Posted Dec 7, 2008 19:02 UTC (Sun) by oak (guest, #2786) [Link]
> Or better: why does Ubuntu need to re-package the Debian packages? Even
debianutils is re-packaged!
Some reasons for doing this:
* Ubuntu does releases at different time from Debian (much more often).
* Binary packages re-compilation (if that's what you meant
* There are also some differences in Ubuntu base system (Upstart several
Losses at Mandriva Posted Dec 2, 2008 20:52 UTC (Tue) by MattPerry (guest, #46341) [Link]
> 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
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.
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:14 UTC (Wed) by flewellyn (subscriber, #5047) [Link] I'm both saddened and disappointed that you feel my question was flippant. I believe he was speaking of his other reply, "Because ours are better", as the "equally flippant" one. Not your question.
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 3, 2008 10:15 UTC (Wed) by Los__D (subscriber, #15263) [Link] I'm both saddened and disappointed that you feel my question was flippant. I think he's referring to his own Because our packages are better, of course, not your post.
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.
Losses at upstreams Posted Dec 12, 2008 15:53 UTC (Fri) by gvy (guest, #11981) [Link]
Weeeeell, probably some sort of "adoptarium" for the needed part of that orphanage might help. IIRC there was something created or announced on LWN several months ago, but I've forgot the name already (ouch!).
Consider dhcpcd which was effectively a dead upstream until Debian and Gentoo maintainers decided to br^H^Htake it over.
Culture of wrappers and workarounds Posted Dec 5, 2008 14:33 UTC (Fri) by nhippi (subscriber, #34640) [Link]
> To take a random example, I maintain opensync for Mandriva. I use version 0.22, because it actually freaking works. Fedora has 0.3, because it's a bigger number and KDE 4 expects it to be there (never mind that KDE 4 cannot do anything at all useful with opensync).
This is actually part of the disaster created by distributions. Instead of fixing things (like opensync 0.3), distributors choose to revert to old versions. Or create wrappers/horrible patches.
A great example is X. For years and years distros competed on who had the shiniest XF86Config generator scripts. Each and every distro duplicated that work. Then finally one day upstream went and implemented autoconfiguring. All that duplicated work.. down in history.
Had distributors worked from the beginning withing X to add autoconfiguring and sane defaults instead of attempted to add value to their own distro, how much further would be today?
Distros seem to thrive with the "Dont fix it, workaround it. Or add a wrapper. Whatever you do, don't co-operate with upstream." culture.
Culture of implementing on crack Posted Dec 12, 2008 15:56 UTC (Fri) by gvy (guest, #11981) [Link]
> Then finally one day upstream went and implemented autoconfiguring.
...breaking things for everyone. Yes, from modelines to 96dpi on ati and 120dpi screen.
Theory and practice are closer in theory than in practice. And distros are closer to users than upstreams usually. (implementors and supporters are closer yet, so there's at least one more similar round)
|
|
||||||||||||