2 Nov
2019
2 Nov
'19
9:31 p.m.
And Chris's answer.
---------- Forwarded message ---------
From: Chris Bennett <chris(a)bennettconstruction.us
Date: Sat, Nov 2, 2019 at 10:25 PM
Subject: Re: [ledgersmb-devel] Porting to OpenBSD again
To: Erik Huelsmann <ehuels(a)gmail.com
On Sat, Nov 02, 2019 at 09:20:57PM +0100, Erik Huelsmann wrote:
I am thinking that the most useful thing will turn out to be some
installation details for different web servers. That could be a longish
list since there are quite a few choices. Putting that into the final
package would be pretty cumbersome. And too much work to keep it always
up to date. The base httpd server in OpenBSD can be run in quite a few
different ways. But that's for much later.
You can close the issues on github. I did manage to miss the 1.7
instructions.
Thanks,
Chris Bennett
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
If you want to be running linux from a usb stick, I
think a distribution
with a
Live version will help. (I'd suggest DebianLive,
because we have regularly
updated Debian packages.)
Sounds good.
I really don't expect you will need to change much on the project's
source
code
-- which would be a primary reason to create a branch.
I *can* imagine
though
that you'll need to store a lot of code/changes
required to do the
porting of
the Perl packages you listed in one of the tickets
into OpenBSD. Because
development of packages is usually tangent on the development of the
project
itself, we've created package repositories within
the GitHub 'ledgersmb'
organisation: https://github.com/ledgersmb/ledgersmb-docker for the Docker
packages/images, https://github.com/ledgersmb/pkg-ledgersmb for the Debian
package and https://github.com/ledgersmb/lsmb-overlay for a Gentoo Overlay
(package).
We could create another repository for the OpenBSD package(s), if that
helps?
2 Nov
2 Nov
9:53 p.m.
Let me see if I am understanding something.
I've been running baremetal, since forever.
But not everybody can do that or get the privilege to get Perl modules
installed.
So is the intent of building a localized Perl and local::lib to get
around that problem? If so, that would be pretty important.
Thanks,
Chris Bennett
3 Nov
3 Nov
4:02 p.m.
New subject: Fwd: Porting to OpenBSD again
Hi Chris,
On Sat, Nov 2, 2019 at 10:53 PM Chris Bennett <chris(a)bennettconstruction.us>
wrote:
Let me see if I am understanding something.
I've been running baremetal, since forever.
But not everybody can do that or get the privilege to get Perl modules
installed.
Right. That's where 'local::lib' comes in: it's a place where additional
modules can be installed by the regular CPAN 'module manager tools' (cpan /
cpanm / etc).
So is the intent of building a localized Perl and
local::lib to get
around that problem?
"local::lib" and "localized Perl" (or: using non-system Perl) are to
different technical solutions for, I think, two different problems.
When an admin can't get access to install his own Perl modules, depending
on "local::lib" can help to build a layer of user-specific modules on top
of the system-provided modules. (Note that this is *not* dependent on
installing a Perl version along side the one already provided by the
system.)
When the system provides a Perl version that's too old for the software to
run on, installing a newer version along side the system Perl might be a
solution. One way to do that is to use 'perlbrew'; another is to use
'plenv'.
Normally, I would resort only to one of these options when the distribution
I'm using doesn't provide the required packages. That is, if I were a
LedgerSMB user (as opposed to the developer that I actually am), I'd use
the Debian packages that come with the distro (or head over to Jame's PPA
to install his package of a newer version).
If so, that would be pretty important.
If you're going to develop packages for your OS/distribution, I think you
should use the method expected by admins of the platform. That is: if
there's a Drupal package and that package *includes* (as opposed to
"depends on") a PHP interpreter, then it's appropriate to include a Perl
interpreter when distributing LedgerSMB. If such packages do not come
standard on the OS, then I'd say admins will expect you to use the system
Perl interpreter. The Perl modules that LedgerSMB depends upon will have to
be turned into OS packages too, so that the LedgerSMB package can depend on
it and pull the packages in when the LedgerSMB package gets installed.
Regards,
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
1233
days inactive
1234
days old
2 comments
2 participants
participants (2)
-
Chris Bennett -
Erik Huelsmann