[opensuse-buildservice] Software installation
Hi, I just read this: http://ianmurdock.com/?p=388 It's a blog about why software installation sucks on Linux. He is right with many of his statements, we all experienced that in the past. Distributions took that job and improved a lot. 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. That's another area where the buildservice really can make a difference. 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. Since maintaining lots of stuff is a cost factor for ISVs, I think that would be one additonal argument to port to Linux. True? Klaas --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
-----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/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFiIq0r3NMWliFcXcRAoFdAKCBSRL0QhYZaIFUD9UUiXhoWUtcawCgrz8R 3UhV0TTzYJ+zMMztTGj1oHI= =LJj0 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Op woensdag 20 december 2006 01:58, schreef Pascal Bleser:
- 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 isn't rpm the preferred packaging method in LSB? Build problem solved as all packages should actually use spec files ;) -- Richard Bos Without a home the journey is endless --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
- - 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. I disagree, especially about the part "they evolve very quickly". I of cause like to use the newest gcc/gfortran, KDE, Firefox, etc. But if I buy commercial software (Mathematica, NAG f95, Corel Draw Linux [well, does not work anymore :-(], etc.), I expect that that software still works if I update my Linux. LSB might be the lowest common denominator, but if I have an LSB
Hi, Pascal Beser wrote: package, I can be sure it works. Besides: Even if someone builds a package, which is not for "LSB", the normative power of the LSB makes sure that certain things work (e.g. using /usr/lib/lsb/install_initd). The process is slow, but it really helps! (I in fact like standards, in the old days, gcc had several extensions, other C compilers had others etc. Now several extensions are in the C99 standard and every compiler vendor tries to comply to that standard. For Fortran 77 the situation was even worse [Fortran 90 consolidated the differences].) Richard Bos wrote:
Op woensdag 20 december 2006 01:58, schreef Pascal Bleser:
- 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.
Well, chkconfig is not part of LSB, even if it is mentioned in some nonnormative note. It is a while back that I wrote LSB complient init scripts, they worked under Debian 3.0, I don't think Debian broke it. (Ok, the dependency calculation of install_initd was sort of a hack in Debian, but worked for my scripts.)
And isn't rpm the preferred packaging method in LSB? Build problem solved as all packages should actually use spec files ;)
Yes, but it is a restricted RPM format (some RPM features are not allowed), in addition you are only allowed to depend on LSB-Provided things (or those which you provide yourself). Installing LSB-RPM-Packages with "alien" worked ok under Debian 3.0 as far as I can tell. (There were not that many LSB packages at that time - and not many are currently available either.) Tobias, who extended the init-scripts part of the LSB three years ago, based on the needs as system administrator for O(400) Debian computers. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Am Tuesday 19 December 2006 23:41 schrieb Klaas Freitag:
Hi,
I just read this: http://ianmurdock.com/?p=388
It's a blog about why software installation sucks on Linux. He is right with many of his statements, we all experienced that in the past. Distributions took that job and improved a lot.
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.
That's another area where the buildservice really can make a difference.
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.
this would only partly solve his problems, he wrote a lot from the user point of view. And the user has the hazzles because of unstable ABIs on Linux. What we could consider is to create a pool of standarised packages (on top of LSB project), which should work on all distributions. When you connect this with a thing like klik, we could theoretical reach a 100% one click and run on all systems solution. A generalised build description (and templates) makes of course anyway sense to make build way easier, more portable and maybe also automated.
Since maintaining lots of stuff is a cost factor for ISVs, I think that would be one additonal argument to port to Linux.
I think ISV's would prefer the single package solution before a multiple package solution. At least as long as all features do work on all systems and they do not need to integrate deeper into the systems. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (5)
-
Adrian Schröter -
Klaas Freitag -
Pascal Bleser -
Richard Bos -
Tobias Burnus