-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Klaas Freitag wrote: ...
But still there are problems: For ISVs, for organisations who want to stay distribution independent and for the lots of developers whos work did not yet make it to a distribution.
It's very much work to maintain all the building instructions for the various distributions out there in case you just want to code (and unfortunately people like to use your code) and your hobby is not packaging. You hardly have a chance to get many rpms for your project from outside unless it's really prominent.
I think the issues for ISVs are not only packaging but also differences wrt proper integration. Just a few examples off the top of my head: - - init scripts are incompatible (e.g. SUSE vs Redhat vs Debian) - - you can hook into yast2 on SUSE with /etc/sysconfig/ (or even a YaST module) but.. that's SUSE only - - different paths for e.g. KDE, GNOME, Firefox, ... - - different core tools available (e.g. Redhat/FC have some su-helper that uses PAM, SUSE doesn't have it at all) Some more thoughts are in this comment I made on Mark Shuttleworth's blog when he started some "visionary" [1] babbling about "Consistent Packaging": http://www.markshuttleworth.com/archives/66#comment-11318 [1] vi·sion·ar·y, adj.: an excuse for not having a clue what you're talking about
That's another area where the buildservice really can make a difference.
IMO the build service only solves the easiest part of the job. ISVs could already host their own VMs or chroots of the distributions they want to support and use spec file templates (or the control stuff for debs) with some scripting. The build service doesn't solve e.g. having different init scripts on every distribution. You have to solve it with different Source files and %if macros. One doesn't need the build service for that ;) Obviously, the build service *does* help because it can provide an infrastructure ISVs don't need to host on their own. It's definitely a very interesting option, but as said, IMO it only solves the easiest part of the problem. I think LSB is a dead cow for various reasons: - - It's a committee with a standard: standards and specifications that try to unify are almost always behind the real-world requirements at some point in time, and I think this is especially true wrt Linux distributions as they evolve very quickly. - - It's still not supported by most distributions: SUSE seems to be highly LSB compliant but what about others ? Just as an example, Debian/Ubuntu don't even have chkconfig installed by default and have a different init script scheme. And I won't even mention the simplest part of LSB which is the FHS (File Hierarchy Standard): it is still insufficiently specified and not fully applied on all distributions (at least, AFAICT) - - Linux distributors don't really want to standardize. I mean, c'mon, LSB isn't applied everywhere right now and it's not exactly something new. Enterprise distributions (SLES, RHES) probably want to keep some degree of idiosyncrasy because they're battling for market share (although there's still a lot of market share left for both of them), the Debian folks always think they have the better concept anyway, etc...
Moreover if we in once can think of a more general build description - which could be a meta-description of spec files, we could ease the pain of the people who have to maintain so many different spec files and others for different platforms.
I'd still want to see something like that. Somehow I don't quite believe in some meta-build specification that would actually work :\
Since maintaining lots of stuff is a cost factor for ISVs, I think that would be one additonal argument to port to Linux.
True?
Partly, yes ;))
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\