| |||||||||||||
|
| |||||||||||||
Losses at MandrivaLosses at MandrivaPosted Dec 2, 2008 20:07 UTC (Tue) by avik (subscriber, #704)In reply to: Losses at Mandriva by AdamW Parent article: Losses at Mandriva
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).
(Log in to post comments)
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.
|
|
||||||||||||