Re: Helping new installs find the right dependencies?

Just to add some thoughts here.

On Sat, Mar 22, 2014 at 12:11 PM, Erik Huelsmann <..hidden..> wrote:

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...

My thinking is that such would be included relative to the application directory. Thus an upgrade of LSMB would install the latest of these as well.

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

To be honest *these* problems are ones that should be looked at primarily through the module selection process or pushed back to maintainers. Those which are particular problems we may want to move away from. If we need to solve this with specific modules for our "with deps" tarball, we might want to be more selective on which ones are likely problems. Anything we do with a deps tarball should be as a stop-gap for specific problems if these are the goals.

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

I see a somewhat different problem (or actually two problems), which to be honest I am now in a position to help with a bit more. The scenario is this:

Someone runs Makefile.PL, and then runs make, and it downloads dependencies. Somewhere along the line something breaks for some obscure reason and it can be difficult to track the failure down. Key failure cases are LaTeX::Driver, Template::Latex, and some other modules. The XS modules may lack dependencies also but we can't fix that with a with-deps distribution.

The second problem is that I have not been entirely happy with Module::Install here with anything I have released on CPAN. In general I have found ExtUtils::MakeMaker to be far more robust even if it is quite different in approach (and we'd need a new makefile). I wouldn't be surprised if some of our installation issues are there.

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.

I can start trying to get us in Fedora.

> 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.

To be clear though, with the exception of the Template::Latex failures, our big issues here that I know of have been changes breaking our code or failing to compile because of external dependencies.

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?

Just an idea, along these lines.

Suppose instead of a tarball with dependencies, suppose we release an ISO image containing LedgerSMB and all dependencies (pure Perl and Perl XS). If we want to we can also include source distributions of PostgreSQL as well, or a minimal set of TexLive. Such an ISO would probably be smaller than the typical set of TexLive anyway even including everything.

An ISO would also be nice for things like offline installations.

> 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.

Now that we have branched 1.4, I would like to take the Makefile.PL and move it to ExtUtils::MakeMaker. This changes dependencies, but I don't think we'd have a problem pushing it for 1.5.

--
Bye,

Erik.

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

Robust and Flexible. No vendor lock-in.

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Best Wishes,

Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.

http://www.efficito.com/learn_more