Re: Helping new installs find the right dependencies?

Hi Robert,

Thanks for your feedback. Long response, don't mean to be defensive, rather, I'd like to explore if I understand your line of thought, by providing more insight - I hope - in mine.

> Recent discussions - both on the mailing lists and through private mail -

> show that people still find it hard (or even very hard) to get and install
> the right dependencies.

And yes, determining why that is, I agree is something we should help with...

> My thinking is that we can help admins by providing a tarball with all the
> required and optional dependencies which are known to work with LedgerSMB
> (and each other!).

Provide how? Distribution archives? For which versions of LSMB ?
Which Perl versions? Which distros?

Well, my idea is to provide sources which are known to work on a wide range of perl versions, if we can assess that. But never on more versions than those on which LedgerSMB actually works itself...

Regarding distros: this probably wasn't clear from my original mail, but I'd like to target this tarball on distros where the distro repository (or the standard Perl libraries) do not include the dependencies. That is: I'd like the dependency tarball to be generic, starting with a base Perl version and the dependencies which require Perl-XS. The rest, I'm thinking, we could provide through the dependencies tarball. (Note that I'm talking about Perl or "pure Perl" dependencies, not TeTeX or MikTeX, cups or dependencies like that.)

> That would remove the need for admins installing LSMB to go out to CPAN.

How can that be a good thing?

Well, I didn't call it a good thing or a bad thing. What I noticed is that admins find our installation process too complex, due to LedgerSMB depending on lots of libraries. My reading from the conversations that I hear and read, the admins installing LedgerSMB see having to go to CPAN as a hurdle.

Now, if you ask me why going to CPAN might be conceived as a hurdle, I can come up with a few reasons:

* CPAN delivers software versions of libraries which don't work together (incompatible libraries)

* CPAN delivers software versions too new to work with the software you're installing

* CPAN installs mix with the installs from the distro repository, leading to "polluted" Perl distro library directories

These are the reasons I can come up with; whether they actually apply, I don't know.

How would they then get security and other updates?

Let me start by saying I think that providing a dependencies tarball is only a workaround: If LedgerSMB is in the distro-repository, using that should be preferred over installing your own exactly because of this reason. However, given the fact that we're actually not included in many distros (at this point I know only of Debian, in fact), we see lots of people installing the software by themselves. At that point, I'm affraid, we can't do anything but declare them responsible to manage their security updates themselves.

> How do others feel about providing such a deps-tarball?

Not a good a good idea, I don't think... Too much of a support problem.

> Would it help solve the dependencies issue?

Better to identify why people might be having problems getting

them via their package manager or cpan.

Well, if their distro is anything other than Debian, isn't the problem that they can't get it through their package manager simply because nobody had the need to package them, given that LedgerSMB (or other projects depending on them) have not been packaged? That leaves CPAN. While I think CPAN is a great idea, I don't think its implementation results in a state where every combination of all libraries in it will be usable, like what the Debian stable repository does a good job of approaching very closely. My expectation is that there will always be people who are either hesitant to get software from CPAN or who are running into CPAN version mismatches. Especially the latter we can't prevent: cpan changes continuously. With a dependencies tarball, we can provide our users a resource they can use to install (but won't *have* to, if their distro repository provides the packages as well), which we *know* to be working with the version of LedgerSMB we're releasing.

Do you think we can resolve the issues in the paragraph above? (Apart from looking very hard for maintainers for other distros which I sincerely hope we can find really soon.) If so, how?

> Does anybody have experience doing so for a Perl project ....?
I've experience attempting to provide tech support for apps that
do that (I work at a web and server hosting company, besides what I do
myself), which is why I don't think it's a good idea.

Thanks for your feedback, I think it's very valuable. Did you respond from a background where the software you had to do tech support for incorporated publicly available libraries? Or did they force-install their own versions? Or did the person installing choose to install the libraries from an unmaintained source, quite deliberately, him/herself? This point is quite important in my opinion, because I want neither the first nor the second situation for LedgerSMB.

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.