ledgersmb / LedgerSMB

Double-entry accounting & ERP for the web
https://ledgersmb.org
Other
426 stars 152 forks source link

Go through deb packages to see what should be mainlined #3012

Closed einhverfr closed 7 years ago

einhverfr commented 7 years ago

In the interest of helping make LedgerSMB more packable, I would like to start by going through the patches in the pkg-ledgersmb repos and seeing what we should move into master. I would also like to see what we can do to minimise the packaging impact on the codebase as we can (providing hooks in the right places).

sbts commented 7 years ago

@einhverfr I agree a review and possibly adding some hooks is a good idea. However from much discussion in #ledgersmb over the last 2 years the consensus has been to keep packaging in external repos. I would need a compelling reason to consider merging packaging back into the main repo.

One reason for this is its easier from a packaging perspective as the packages have absolutely no need to obtain a clone of the main repo (and they shouldn't have either) Packages should, (unless it's a master dev package which is pointless as a manual git clone makes more sense) and currently do, retrieve the release tarball and build from there.

jame commented 7 years ago

@einhverfr Please note that I have been using the development of the ledgersmb-1.5 pkg for what' s needed for Debian packageing LedgerSMB 1.5.x and debian/patches is one the things I haven't yet sync'ed over to pkg-ledgersmb. I'll work on that, but note that hopefully all that will be needed to be patched is making it specific to Debian, like installation paths & etc. But otherwise, it's not entirely clear to what this issue is for...

ehuelsmann commented 7 years ago

I just went over the deb package "patches" directory. The patches there patch documents we explicitly left to be patched (WORKING_DIR => your-directory).

There are no other patches, really. I explicitly went over Jame's wishes with him to help out with the packaging. All of that was included in 1.5.7 or '8.

Concluding: at this point there doesn't seem to be abetting we can do to facilitate our packages better. We should remain in close contact of course!

As sbts points out, we want the packages developed in separate repositories because the activities really have independent time lines.

jame commented 7 years ago

@sbts It's not clear to me that what @einhverfr is referring has to do with

merging packaging back into the main repo",

but I do agree that the packaging should stay separate from the main LSMB repository. I originally tried that when I first migrated the old SVN packaging repository to GIT but it just didn't work out (because of tagging, if nothing else), so I created a separate repository for it.

einhverfr commented 7 years ago

So an interesting question might be: it looks like the main config files in most packages will live in /etc/. How can we more readily make that configurable?

sbts commented 7 years ago

@einhverfr we already have! There are several mechanisms at play.

einhverfr commented 7 years ago

But in these cases, putting the config file /etc/ directory requires patching the source if done for a package, I think. Maybe we could expand that last one to allow a build option to set the location? Perhaps in the Makefile?

sbts commented 7 years ago

@einhverfr sorry I don't quite understand. There is no need to patch the source to set the config file location at all. Instead the installation part of the package simply needs to either set a global environment variable, or set it within the systemd service file This is not really any different from any other daemon.

I did consider searching for a config file in a hardcoded list of dir's and using the first found but that could result in difficult to track down issues if there are other config files on a system. Better to have good defaults so things will work "out of the box" and default to expecting the config file in the same dir as the source.

By adding the ENV Var as an override to the location, any system specific location can be used. More importantly, it makes supporting multiple LedgerSMB instances on the same OS installation trivial as well, even if they all need the same config file (or different ones)

Even if a distro package doesn't want to set an ENV Var, all they have ever needed to do was create a symlink in the installation dir pointing at eg: /etc/ledgersmb/ledgersmb.conf

jame commented 7 years ago

@sbts @einhverfr @ehuelsmann That's what I've done for the LSMB config file; patched the service file (& the sysv init file I added) for the LSMB_CONFIG_FILE variable. 'Course, I don't yet know that it works... (I have that in the ledgersmb-1.5 pkg and I'm working on sync'ing changes like that to the ledersmb pkg.) Also have already had a sym link pointing to the config file but that's more for anyone looking in the install directory for where the working config file is than for just setting the LSMB config.