Re: [Koha] ANNOUNCE: Koha perl dependency RPMs for Red Hat 9
"it would really help a lot of not-so-IT librarians to just install Koha without them knowing the hard work." Correct.. In this manner and other things leading to the one click instal, shall any software package gain universal acceptance... Ed Sharpe archivist for SMECC
Subj:Re: [Koha] ANNOUNCE: Koha perl dependency RPMs for Red Hat 9 Date:6/22/2003 5:26:46 AM US Mountain Standard Time From:<A HREF="mailto:sweet@pchrd.dost.gov.ph">sweet@pchrd.dost.gov.ph</A> To:<A HREF="mailto:koha@lists.katipo.co.nz">koha@lists.katipo.co.nz</A> Sent from the Internet
i might even manage an RPM package for Koha itself. <g>
Paul
hopefully, this would come to fruition. it would really help a lot of not-so-IT librarians to just install Koha without them knowing the hard work.
cheers!
louella _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Thanks Ed Sharpe, Archivist for SMECC See the Museum's Web Site at www.smecc.org We are always looking for items to add to the museum's display and ref. library please advise if you have anything we can use. mail: Coury House / SMECC 5802 W. Palmaire Ave. Glendale Az 85301 USA 623-435-1522
On Monday 23 June 2003 01:22 am, COURYHOUSE@aol.com wrote:
"it would really help a lot of not-so-IT librarians to just install Koha without them knowing the hard work."
Correct.. In this manner and other things leading to the one click instal, shall any software package gain universal acceptance...
A manager once put me right on this point. Your application might be the best in the world, but if the install isn't easy, or doesn't work right, the user will never see how good it is. This is a problem with open source in general - that installation is far harder than with commercial applications. Developers know how to build and deploy, while users are not conversant with the tools - and shouldn't need to be. Regards, Peter
On Mon 23 Jun 2003 at 08:22:06 +1200, Peter Harrison wrote:
On Monday 23 June 2003 01:22 am, COURYHOUSE@aol.com wrote:
"it would really help a lot of not-so-IT librarians to just install Koha without them knowing the hard work."
Correct.. In this manner and other things leading to the one click instal, shall any software package gain universal acceptance...
A manager once put me right on this point. Your application might be the best in the world, but if the install isn't easy, or doesn't work right, the user will never see how good it is.
That's a fair point, but it reminds me of the old adage: "Good, cheap, fast: choose any two." I'm not sure exactly how the adage would be worded as it relates to software installation, but I'm increasingly of the opinion that software which is functional, easy to install, and easy to upgrade is becoming increasingly harder to create.
This is a problem with open source in general - that installation is far harder than with commercial applications. Developers know how to build and deploy, while users are not conversant with the tools - and shouldn't need to be.
Again, I agree. But that's why there are IT people -- system administrators, in particular -- who bridge the gap between users and software developers/vendors by installing and maintaining software. And regarding open source, there are many reasons why installation is often harder than for a similar commercial application. But the blame for that should usually be shared between the open-source application and the open-source operating system it runs on. My own experience is that Debian GNU/Linux makes it much easier to install software than RPM-based distributions (such as Red Hat). But there's no free lunch: packaging software for Debian is harder because of the more stringent quality controls which are required. What does all this mean for Koha? Well, I'm not a Koha developer (not even a user yet, although I hope to persuade our library one day), but here are the options as I see them to make installation easier: 1. Provide Koha packaged for each OS you want to support (e.g. Red Hat, Debian, SuSE, etc., or Windows even). In some cases this might require also supplying the required supporting packages (which is what started this whole discussion thread, I believe). The packaging of Koha for different distributions could be contributed by people other than core development people if necessary. 2. Provide Koha packaged for a single Linux distribution, and possibly incorporated on a custom Linux install CD image. 3. Improve the install scripts to check for required Perl modules and install them from CPAN if necessary. Any of those would mean considerable work, but should improve the ease of installation. (If we ever moved to Koha, we'd probably be able to contribute Debian packages.) But I guess the main point I'm trying to make is that users need to be realistic in their expectations of the installation process. To quote (possibly misquote) Einstein, things should be made as simple as possible, but no simpler. Tim. -- Tim Bell -- bhat@trinity.unimelb.edu.au -- System Administrator Trinity College, Royal Parade, Parkville, Victoria, 3052, Australia
"Tim" == Tim Bell <bhat@trinity.unimelb.edu.au> writes: Tim> On Mon 23 Jun 2003 at 08:22:06 +1200, Peter Harrison wrote: >> On Monday 23 June 2003 01:22 am, COURYHOUSE@aol.com wrote: > "it >> would really help a lot of not-so-IT librarians to just install >> Koha > without them knowing the hard work." > > Correct.. In >> this manner and other things leading to the one click instal, > >> shall any software package gain universal acceptance... I don't see how the install can get much simpler, given Koha's dependency on other software. I've installed three versions of Koha on three versions of Linux, and it has always been a simple matter after I've insured all the right Perl modules are in place. >> A manager once put me right on this point. Your application might >> be the best in the world, but if the install isn't easy, or >> doesn't work right, the user will never see how good it is. This assumes that the end user should be the one responsible for installing the software. I'm not sure this is a valid assumption for a complex, flexible application that depends on other applications being correctly installed before it can function. After it is installed, Koha has proven stable, efficient and extremely easy to use for our library. <snip> Tim> What does all this mean for Koha? Well, I'm not a Koha Tim> developer (not even a user yet, although I hope to persuade our Tim> library one day), but here are the options as I see them to Tim> make installation easier: <snip of installation options> These are all good options, but I would put them pretty low on the development priority list right now, unless there is somebody new willing to take on these tasks. Getting a stable version out that includes most needed features should take priority, IMO. Tim> But I guess the main point I'm trying to make is that users Tim> need to be realistic in their expectations of the installation Tim> process. To quote (possibly misquote) Einstein, things should Tim> be made as simple as possible, but no simpler. I agree. Koha is not really a good choice for a library without IT people available as of now, but having watched a linux neophyte install it with no trouble I would say the install is not overly complex. -- Larry Stamm, Chair McBride and District Public Library McBride, BC V0J 2E0 Canada http://www.mcbridebc.org/library
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tim Bell wrote:
... And regarding open source, there are many reasons why installation is often harder than for a similar commercial application. But the blame for that should usually be shared between the open-source application and the open-source operating system it runs on. My own experience is that Debian GNU/Linux makes it much easier to install software than RPM-based distributions (such as Red Hat). But there's no free lunch: packaging software for Debian is harder because of the more stringent quality controls which are required.
I never have understood, and still don't understand, why people think typing 'rpm -Uvh packagename' is hard. Red Hat doesn't have the advantage/disadvantage of being a single unified project. Every man and his dog makes RPM packages, many of them not free, so there is no authoritative source from which to resolve dependencies. Thus, the responsibility to find the correct packages is left with the user. However, that still doesn't make it hard to install software.
... What does all this mean for Koha? Well, I'm not a Koha developer (not even a user yet, although I hope to persuade our library one day), but here are the options as I see them to make installation easier:
1. Provide Koha packaged for each OS you want to support (e.g. Red Hat, Debian, SuSE, etc., or Windows even). In some cases this might require also supplying the required supporting packages (which is what started this whole discussion thread, I believe).
What other way is there? Users don't compile, users install. The FreeBSD/Gentoo philosophy of making every end user a build engineer is ludicrous, in my opinion. I started programming in C over 15 years ago, but i am not the slightest bit interested in recompiling ls and vi and other core utilities when i install an OS (not to mention wasting breath and time sitting there watching it recompile). For widespread use, an installable package native to the given OS is essential.
The packaging of Koha for different distributions could be contributed by people other than core development people if necessary.
I would say this is essential. If you're Debian people and it works for you, there's no incentive to make RPM packages. If you're like me and can't stand seeing any software on the box not being controlled by the native software management system, the incentive is there.
2. Provide Koha packaged for a single Linux distribution, and possibly incorporated on a custom Linux install CD image.
In my experience, this makes it a pain to install for people who want to use the software but are competent with a different OS, and more significantly, requires people to have a dedicated server if they don't already have a like system. This was recently illustrated for me by the content filtering system CensorNet. It is a Debian-based standalone distribution that combines Dan's Guardian with a web frontend and an image filter that (theoretically) blocks certain types of images based on content. However, since i'm more familiar with Red Hat, installing LAN cards was a pain, as was their access control (based upon MAC addresses rather than IP addresses - they assume people will run DHCP with dynamic addressing). So the software was not a good fit for my environment and i decided not to use it, because sticking with the distribution i know means saved time and headaches.
3. Improve the install scripts to check for required Perl modules and install them from CPAN if necessary.
Those of us in the RPM mould find CPAN installation intolerable (not to mention a pain), because you can't find out all the packages that are installed from one interface. That's why i made the RPMs to provide perl dependencies.
... But I guess the main point I'm trying to make is that users need to be realistic in their expectations of the installation process. To quote (possibly misquote) Einstein, things should be made as simple as possible, but no simpler.
Having installed two different versions of Koha from scratch now, on two different versions of Red Hat, my opinion is that the installation process could be made quite a bit simpler (at least on Red Hat ;-) by providing preconfigured defaults for most of the installation parameters (not the library parameters that Paul P. mentioned earlier, just the installation-related stuff like paths, ports, hostnames, etc.). If i get a chance i might try to whip up an RPM that does this in the next few weeks/months. I think it might require some adjustments to the installer, but i'm sure the Koha team will be willing to accept patches. :-) Paul http://paulgear.webhop.net P.S. Are my packages going to be put on sourceforge? Don't i deserve my millisecond of glory? :-) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+9uAZ0yv0OWRYqWwRApE1AKDO8XbOypRzIewMVN6y0BMv/FmpgQCfZmf9 sBcbIMNxWtsXV1JD7lw2dEo= =mAyp -----END PGP SIGNATURE-----
Paul Gear <paul@gear.dyndns.org> wrote:
I never have understood, and still don't understand, why people think typing 'rpm -Uvh packagename' is hard.
Because you have to find packagename's rpm first. Debian doesn't normally need you to do that. [...]
What other way is there? Users don't compile, users install. The FreeBSD/Gentoo philosophy of making every end user a build engineer is ludicrous, in my opinion. I started programming in C over 15 years ago, but i am not the slightest bit interested in recompiling [...]
Similarly, you're probably not the slightest bit interested in whether it recompiles as you install it, so I've never understood that argument.
[...] So the software was not a good fit for my environment and i decided not to use it, because sticking with the distribution i know means saved time and headaches.
Please learn useful standards like Linux Standard Base instead of a particular distribution if you are a sysadmin. [...]
next few weeks/months. I think it might require some adjustments to the installer, but i'm sure the Koha team will be willing to accept patches. :-)
Please. I'd appreciate you participating on koha-devel while doing this. I'll probably not be at this week's devel IRC meeting (because I'm at the Birmingham Linux User Expo) but you can always contact me otherwise.
P.S. Are my packages going to be put on sourceforge? Don't i deserve my millisecond of glory? :-)
Have you GPG signed them? -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ jabber://slef@jabber.at Creative copyleft computing services via http://www.ttllp.co.uk/ Thought: "Changeset algebra is really difficult."
On Mon, 23 Jun 2003, MJ Ray wrote:
Paul Gear <paul@gear.dyndns.org> wrote:
I never have understood, and still don't understand, why people think typing 'rpm -Uvh packagename' is hard.
Because you have to find packagename's rpm first. Debian doesn't normally need you to do that.
apt-get is available for RPM also and does wonderful things just like on debian, but no one has yet built the humongous library of interworking packages the way the legion of debian package maintainers has. Speaking koha-specifically, someone with the time to maintain such a thing could setup an aptrpm repository somewhere. Please, please, please. :) http://freshrpms.net/ explains how to do it.
[...] So the software was not a good fit for my environment and i decided not to use it, because sticking with the distribution i know means saved time and headaches.
Please learn useful standards like Linux Standard Base instead of a particular distribution if you are a sysadmin.
The LSB is wonderful as far as it goes and most of it seems natural to any Linux admin, but the LSB will never cover the mass of knowledge that will continue to be very vendor/distro-specific. For instance, "these are the stable RH releases". These are the debian kernel releases to avoid. And so on. Minimizing the number of unknowns is a good strategy as long you don't become stuck in one distro/vendor and never get any perspective. -- </chris> The death of democracy is not likely to be an assassination from ambush. It will be a slow extinction from apathy, indifference, and undernourishment. -Robert Maynard Hutchins, educator (1899-1977)
Christopher Hicks wrote:
On Mon, 23 Jun 2003, MJ Ray wrote:
Paul Gear <paul@gear.dyndns.org> wrote:
I never have understood, and still don't understand, why people think typing 'rpm -Uvh packagename' is hard.
Because you have to find packagename's rpm first. Debian doesn't normally need you to do that.
apt-get is available for RPM also and does wonderful things just like on debian, but no one has yet built the humongous library of interworking packages the way the legion of debian package maintainers has.
and on Mandrake (rpm based), you have urpmi. Just type "urpmi what_you_think" and urpmi will tell you what he finds. If dependencies are needed, urpmi installs them too. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
Just an FYI for everyone... to find the packagename if you're not sure, you can do: rpm -qa | grep -i <what you think it may be> rpm -qa will give the list of all packages, piped to grep (the -i ignores case) to search for the name. In RedHat at least, you don't need an RPM for a package to uninstall it. Later, -Al On Mon, 2003-06-23 at 14:00, paul POULAIN wrote:
Christopher Hicks wrote:
On Mon, 23 Jun 2003, MJ Ray wrote:
Paul Gear <paul@gear.dyndns.org> wrote:
I never have understood, and still don't understand, why people think typing 'rpm -Uvh packagename' is hard.
Because you have to find packagename's rpm first. Debian doesn't normally need you to do that.
apt-get is available for RPM also and does wonderful things just like on debian, but no one has yet built the humongous library of interworking packages the way the legion of debian package maintainers has.
and on Mandrake (rpm based), you have urpmi. Just type "urpmi what_you_think" and urpmi will tell you what he finds. If dependencies are needed, urpmi installs them too.
-- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 MJ Ray wrote:
Paul Gear <paul@gear.dyndns.org> wrote:
I never have understood, and still don't understand, why people think typing 'rpm -Uvh packagename' is hard.
Because you have to find packagename's rpm first. Debian doesn't normally need you to do that.
(We probably should take this to a more appropriate forum...) Haven't we already covered this ground? What do you do for software that's not part of the Debian project? You have to go find it just like you do for RPMs. Is Koha part of the Debian project yet? Evidently not: http://packages.debian.org/cgi-bin/search_packages.pl?keywords=koha&searchon=names&subword=1&version=all&release=all What do people do in the meantime?
[...]
What other way is there? Users don't compile, users install. The FreeBSD/Gentoo philosophy of making every end user a build engineer is ludicrous, in my opinion. I started programming in C over 15 years ago, but i am not the slightest bit interested in recompiling [...]
Similarly, you're probably not the slightest bit interested in whether it recompiles as you install it, so I've never understood that argument.
Yes, i am, actually. I don't want time spent on doing work that's already been done. There are also other good arguments for *not* recompiling the software on every system system its installed on - witness the recent GCC security advisory. (I'm not sure why this is an issue for discussion, since Debian provides precompiled packages as well, doesn't it?)
[...] So the software was not a good fit for my environment and i decided not to use it, because sticking with the distribution i know means saved time and headaches.
Please learn useful standards like Linux Standard Base instead of a particular distribution if you are a sysadmin.
Every distribution has *something* different about it. How is LSB going to help me know how to control the ethernet module assignments in modules.conf? (P.S. Please let me be the judge of what's useful to me... :-)
[...]
next few weeks/months. I think it might require some adjustments to the installer, but i'm sure the Koha team will be willing to accept patches. :-)
Please. I'd appreciate you participating on koha-devel while doing this. I'll probably not be at this week's devel IRC meeting (because I'm at the Birmingham Linux User Expo) but you can always contact me otherwise.
OK
P.S. Are my packages going to be put on sourceforge? Don't i deserve my millisecond of glory? :-)
Have you GPG signed them?
Have you looked at them? :-) enoch:[/share/rpm/RPMS/noarch]rpm --checksig perl-* perl-Event-0.87-1.noarch.rpm: (sha1) dsa sha1 md5 gpg OK perl-HTML-Template-2.6-1.noarch.rpm: (sha1) dsa sha1 md5 gpg OK perl-MARC-Record-1.29-1.noarch.rpm: (sha1) dsa sha1 md5 gpg OK perl-Mail-Sendmail-0.79-1.noarch.rpm: (sha1) dsa sha1 md5 gpg OK perl-Net-Z3950-0.34-1.noarch.rpm: (sha1) dsa sha1 md5 gpg OK Paul http://paulgear.webhop.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+915l0yv0OWRYqWwRAgXJAJ4/rW353tWUNKKwgI2Hc3Pn1VLplwCgkFSx gXZ7qwRQJzi4V7Ib93YWk70= =Gozq -----END PGP SIGNATURE-----
I agree this would be much better on the devel list. Paul, I have a tarball of your rpms that i will put up on sourceforge as soon as I get a chance. After work today probably. Chris On Tue, Jun 24, 2003 at 06:09:10AM +1000, Paul Gear said:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
MJ Ray wrote:
Paul Gear <paul@gear.dyndns.org> wrote:
I never have understood, and still don't understand, why people think typing 'rpm -Uvh packagename' is hard.
Because you have to find packagename's rpm first. Debian doesn't normally need you to do that.
(We probably should take this to a more appropriate forum...)
Haven't we already covered this ground? What do you do for software that's not part of the Debian project? You have to go find it just like you do for RPMs. Is Koha part of the Debian project yet? Evidently not:
What do people do in the meantime?
[...]
What other way is there? Users don't compile, users install. The FreeBSD/Gentoo philosophy of making every end user a build engineer is ludicrous, in my opinion. I started programming in C over 15 years ago, but i am not the slightest bit interested in recompiling [...]
Similarly, you're probably not the slightest bit interested in whether it recompiles as you install it, so I've never understood that argument.
Yes, i am, actually. I don't want time spent on doing work that's already been done. There are also other good arguments for *not* recompiling the software on every system system its installed on - witness the recent GCC security advisory. (I'm not sure why this is an issue for discussion, since Debian provides precompiled packages as well, doesn't it?)
[...] So the software was not a good fit for my environment and i decided not to use it, because sticking with the distribution i know means saved time and headaches.
Please learn useful standards like Linux Standard Base instead of a particular distribution if you are a sysadmin.
Every distribution has *something* different about it. How is LSB going to help me know how to control the ethernet module assignments in modules.conf?
(P.S. Please let me be the judge of what's useful to me... :-)
[...]
next few weeks/months. I think it might require some adjustments to the installer, but i'm sure the Koha team will be willing to accept patches. :-)
Please. I'd appreciate you participating on koha-devel while doing this. I'll probably not be at this week's devel IRC meeting (because I'm at the Birmingham Linux User Expo) but you can always contact me otherwise.
OK
P.S. Are my packages going to be put on sourceforge? Don't i deserve my millisecond of glory? :-)
Have you GPG signed them?
Have you looked at them? :-)
enoch:[/share/rpm/RPMS/noarch]rpm --checksig perl-* perl-Event-0.87-1.noarch.rpm: (sha1) dsa sha1 md5 gpg OK perl-HTML-Template-2.6-1.noarch.rpm: (sha1) dsa sha1 md5 gpg OK perl-MARC-Record-1.29-1.noarch.rpm: (sha1) dsa sha1 md5 gpg OK perl-Mail-Sendmail-0.79-1.noarch.rpm: (sha1) dsa sha1 md5 gpg OK perl-Net-Z3950-0.34-1.noarch.rpm: (sha1) dsa sha1 md5 gpg OK
Paul http://paulgear.webhop.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE+915l0yv0OWRYqWwRAgXJAJ4/rW353tWUNKKwgI2Hc3Pn1VLplwCgkFSx gXZ7qwRQJzi4V7Ib93YWk70= =Gozq -----END PGP SIGNATURE-----
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Chris Cormack Programmer 027 4500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
Mandi! Paul Gear In chel di` si favelave...
(We probably should take this to a more appropriate forum...)
I think also... but i'm not a perl monger, only a perl kiddie ;), and i've no time to follow another list... ;)))
What do people do in the meantime?
I'm using koha on debian, and i'm triyng to build a koha debian package. I've a koha 1.2.3 debian package, very alpha. Pratically i've simply used dh-make-perl script to automagically create debian package of missing perl modules that koha require. dh-make-perl use CPAN intelligence, so do a really good job (package works very well!), but it is not perfect because, for example, misses the packaging of the documentation and examples. Then, my koha perl package take only the source, apply some very little patches to move some path around, setup a skeleton config file and keep all the (manual) configuration to the user. All z83.50 stuff are untested. Apart that i'm not a debian mantainer, and i think that i've found a task that is not compatible with the spare time i have, i hope that someone would package koha for debian. Better then i do. ;) -- dott. Marco Gaiarin GNUPG Key ID: 240A3D66 Associazione ``La Nostra Famiglia'' http://www.sv.lnf.it/ Polo FVG - Via della Bontà, 7 - 33078 - San Vito al Tagliamento (PN) gaio(at)sv.lnf.it tel +39-0434-842711 fax +39-0434-842797 Proteggiamo l'innovazione in Europa: no ai brevetti software http://swpat.xsec.it/
Marco Gaiarin <gaio@sv.lnf.it> wrote:
Apart that i'm not a debian mantainer, and i think that i've found a task that is not compatible with the spare time i have, i hope that someone would package koha for debian. Better then i do. ;)
I am Debian developer, but producing my own Koha package is not a high enough priority yet (sorry). I would be interested in sponsoring a tidy Debian package for a non-developer if that is ready before me (very likely). Ideally, development should be discussed on koha-devel and on the package request bug at http://bugs.debian.org/186958 -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ jabber://slef@jabber.at Creative copyleft computing services via http://www.ttllp.co.uk/ Thought: "Changeset algebra is really difficult."
Mandi! MJ Ray In chel di` si favelave...
someone would package koha for debian. Better then i do. ;) I am Debian developer, but producing my own Koha package is not a high enough priority yet (sorry). I would be interested in sponsoring a tidy Debian package for a non-developer if that is ready before me (very likely). Ideally, development should be discussed on koha-devel and on the package request bug at http://bugs.debian.org/186958
...some month ago i think this was the perfect things to do: someone that sponsor me and my packages. But really thinkg are changed rapidly since then, and now i've no time to do this. ;( I'm very sorry... i hope someone could continue the development, i've put my packages on: http://tank.sv.lnf.it/~gaio/koha/ so someone could see this. I think that for now will be a very good thing to have at least all the koha perl dependencies fullfilled with correct debian package. If you can sponsor this, or stress the correct debian developer to have these packaged... Thanks. -- dott. Marco Gaiarin GNUPG Key ID: 240A3D66 Associazione ``La Nostra Famiglia'' http://www.sv.lnf.it/ Polo FVG - Via della Bontà, 7 - 33078 - San Vito al Tagliamento (PN) gaio(at)sv.lnf.it tel +39-0434-842711 fax +39-0434-842797 Proteggiamo l'innovazione in Europa: no ai brevetti software http://swpat.xsec.it/
Tim Bell <bhat@trinity.unimelb.edu.au> wrote:
And regarding open source, there are many reasons why installation is often harder than for a similar commercial application. [...]
Please try to remember that some of us sell commercial free software. Free as in freedom, not necessarily price. Maybe you were talking about software you get for free being harder than stuff you pay for, or maybe you were talking about free software installation being harder than proprietary software. The first is probably true, but I think the second is backwards. [...]
3. Improve the install scripts to check for required Perl modules and install them from CPAN if necessary.
We can probably do that, but CPAN messes up package systems, so it couldn't be automatic. The 1.9.x installer already prints the exact commands that the sysadmin can use for CPAN. -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ jabber://slef@jabber.at Creative copyleft computing services via http://www.ttllp.co.uk/ Thought: "Changeset algebra is really difficult."
participants (11)
-
Al Banks -
Chris Cormack -
Christopher Hicks -
COURYHOUSE＠aol.com -
Larry Stamm -
Marco Gaiarin -
MJ Ray -
Paul Gear -
paul POULAIN -
Peter Harrison -
Tim Bell