[PATCH 1/1] Allow installation to /usr/share

[Rob Browning]

From: Martin Höher <mar...@rpdev.net>

This change allows the bup package files to be installed
into /usr/share/bup. This is nice to comply with
packaging guidelines of some Linux distributions (where
/usr/lib or /usr/lib64 are reserved for platform specific
files whereas platform independent ones are going to be
installed in /usr/share).

Signed-off-by: Martin Höher <mar...@rpdev.net>
---

Redirected to the list from a pull request.

main.py | 6 ++++++
1 file changed, 6 insertions(+)

diff --git a/main.py b/main.py
index ef22957..8651d02 100755
--- a/main.py
+++ b/main.py
@@ -19,6 +19,12 @@ if os.path.exists("%s/lib/bup/cmd/." % exeprefix):
cmdpath = "%s/lib/bup/cmd" % exeprefix
libpath = "%s/lib/bup" % exeprefix
resourcepath = libpath
+elif os.path.exists("%s/share/bup/cmd/." % exeprefix):
+ # installed binary in /.../share.
+ # eg. /usr/bin/bup means /usr/share/bup/... is where our libraries are.
+ cmdpath = "%s/share/bup/cmd" % exeprefix
+ libpath = "%s/share/bup" % exeprefix
+ resourcepath = libpath
else:
# running from the src directory without being installed first
cmdpath = os.path.join(exepath, 'cmd')
--
2.8.1

[Rob Browning]

Rob Browning <r...@defaultvalue.org> writes:

> diff --git a/main.py b/main.py
> index ef22957..8651d02 100755
> --- a/main.py
> +++ b/main.py
> @@ -19,6 +19,12 @@ if os.path.exists("%s/lib/bup/cmd/." % exeprefix):
> cmdpath = "%s/lib/bup/cmd" % exeprefix
> libpath = "%s/lib/bup" % exeprefix
> resourcepath = libpath
> +elif os.path.exists("%s/share/bup/cmd/." % exeprefix):
> + # installed binary in /.../share.
> + # eg. /usr/bin/bup means /usr/share/bup/... is where our libraries are.
> + cmdpath = "%s/share/bup/cmd" % exeprefix
> + libpath = "%s/share/bup" % exeprefix
> + resourcepath = libpath

First off, thanks for the help. My initial inclination was to go ahead
and include the changes, but then I realized that they might need a bit
of adjustment.

While I'm in favor of the overall goal, it looks like we may not be able
to switch exclusively to ".../share/". That's because bup does have at
least one architecture specific file, i.e. _helpers.so, which will need
to stay in lib/bup.

Given that, I think we could just have bup search in both lib and share,
and since there's no reason a subcommand can't be a binary, we may want
dual paths for both bup/bup and bup/cmd. i.e.:

.../lib/bup/cmd
.../share/bup/cmd

.../lib/bup/bup
.../share/bup/bup

If that sounds plausible and you're interested in pursuing the changes,
that's great. If not, we'll consider working on this in the future.

Thanks again.
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

[Martin Höher]

Thanks for the hint, never thought about the helper library. Admittedly, all I
wanted to achieve was to get an RPM of bup which is as compliant to Fedora
(which I built the package for) as possible.

Anyway, I will try to have a look into this (maybe during the week) and come
back.

Ciao
Martin

[Rob Browning]

Martin Höher <mar...@rpdev.net> writes:

> Thanks for the hint, never thought about the helper library. Admittedly, all I
> wanted to achieve was to get an RPM of bup which is as compliant to Fedora
> (which I built the package for) as possible.
>
> Anyway, I will try to have a look into this (maybe during the week) and come
> back.

Sounds good, and while I haven't thought hard about everything that
might be needed, if you end up having time to pursue this, it looks like
it might make sense to maintain a list of locations for cmd, instead of
a single string (for calls like usage and subpath), and perhaps we can
add both datapath and libpath (in automake terminology) wherever we're
just adding libpath right now.

Though no idea of that's right -- imagine you'll be able to tell if you
start poking around.

Oh, and while you're more than welcome to fix "make install" too, I can
handle it if that's not quite what you signed on for.

Thanks much