Fpm: Copy of symlink to packing staging dir in v1.9.x

[andreas-bok-sociomantic]

After upgrading to the latest version v1.9.2 I had an error building deb packages where a symlink for the library file wasn't copied to the tmp staging dir, i.e.

Invalid package configuration: Cannot package the path './install/usr/lib/library-file.so', does it exist? {:level=>:error}

Our library distribution is split into normal, debug and development packages. The input files for the fpm is generated by the normal make install. Thus the files in the lib folder are

- library-name.so        -->  library-name.so.1.2.3
- library-name.so.1      -->  library-name.so.1.2.3
- library-name.so.1.2.3

In the case of the development package only the symlink library-name.so is specified in the cmd args to FPM along with include headers, etc

fpm -s dir -t deb \
...
SOME_PATH/library-name.so=/usr/lib/ 

The fix was quite simply, and just required adding the library-name.so to the install path, i.e.

fpm -s dir -t deb \
...
SOME_PATH/library-name.so=/usr/lib/library-name.so

However since the symlink was created correctly in the v1.8.x releases I am just wondering if the error/required change is expected with the upgrade to v1.9.x?

Keep up the good work?

Best

[jordansissel]

This sounds like a regression and a bug

On Sun, Aug 6, 2017 at 1:57 PM Andreas Bok Andersen <
[email protected]> wrote:

After upgrading to the latest version v1.9.2 I had an error building deb
packages where a symlink for the library file wasn't copied to the tmp
staging dir, i.e.

Invalid package configuration: Cannot package the path
'./install/usr/lib/library-file.so', does it exist? {:level=>:error}

Our library distribution is split into normal, debug and development
packages. The input files for the fpm is generated by the normal make
install. Thus the files in the lib folder are

• library-name.so --> library-name.so.1.2.3
• library-name.so.1 --> library-name.so.1.2.3
• library-name.so.1.2.3

In the case of the development package only the symlink library-name.so
is specified in the cmd args to FPM along with include headers, etc

fpm -s dir -t deb \
...
SOME_PATH/library-name.so=/usr/lib/

The fix was quite simply, and just required adding the library-name.so to
the install path, i.e.

fpm -s dir -t deb \
...
SOME_PATH/library-name.so=/usr/lib/library-name.so

However since the symlink was created correctly in the v1.8.x releases I
am just wondering if the error/required change is expected with the upgrade
to v1.9.x?

Keep up the good work?

Best

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jordansissel/fpm/issues/1395, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIC6mD0OSuJ7Ccb_xeSi4aejBdEceUjks5sViibgaJpZM4Ou1vN
.

[nemanja-boric-sociomantic]

I have a feeling this was the PR that affected this: https://github.com/jordansissel/fpm/pull/1253

I think (I haven't looked into it for a while, talking from top of my head) is that this is now consistent with the way how the files are copied. Previously, there was no way to do this, simply because if you would do:

SOME_PATH/library-name.so=/usr/lib/library-name.so

and library-name.so is a symlink, it would put your symlink into:

/usr/lib/library-name.so/library-name.so

which forced all previous usages of this to specify this in a form:

SOME_PATH/library-name.so=/usr/lib/

to avoid this problem.

[nemanja-boric-sociomantic]

Of course, it could be just a bug in that PR, in case both

SOME_PATH/library-name.so=/usr/lib/

and

SOME_PATH/libray-name.so=/usr/lib/library-name.so

should be allowed. I'll take a look today.

:-)

[nemanja-boric-sociomantic]

Hm, yeah, I've put a test for this, so if this doesn't work, it's definitely a bug: https://github.com/jordansissel/fpm/pull/1253/files#diff-1e8f5f9518ffabd0e3af608e359349dcR158

[andreas-bok-sociomantic]

and library-name.so is a symlink, it would put your symlink into:
/usr/lib/library-name.so/library-name.so

@nemanja-boric-sociomantic AFAIU you say that specifying the install path with library-file.so would install the symlink into a subdirectory

Tested how the deb package is installed with this config: https://github.com/sociomantic-tsunami/libdrizzle-redux/pull/199/commits/4beb5c97c2bea9f38abb25d328b6179ec86567fc
AFAICS it installs the lib files/symlinks correctly

-rw-r--r-- 1 root root 2191776 Aug  7 10:01 /usr/lib/libdrizzle-redux.a
lrwxrwxrwx 1 root root      26 Aug  7 10:01 /usr/lib/libdrizzle-redux.so -> libdrizzle-redux.so.10.1.5*
lrwxrwxrwx 1 root root      26 Aug  7 10:01 /usr/lib/libdrizzle-redux.so.10 -> libdrizzle-redux.so.10.1.5*
-rwxr-xr-x 1 root root  109360 Aug  7 10:01 /usr/lib/libdrizzle-redux.so.10.1.5*

SOME_PATH/libray-name.so=/usr/lib/library-name.so

This syntax is already allowed in v1.9.x and 1.8.x

[jordansissel]

hmm.. Trying to think about this (sorry, I am juggling a bunch of other tasks at the moment) --

SOME_PATH/library-name.so=/usr/lib/

I think this should result in a path /usr/lib/library-name.so in the package that has the same link content as the original file, right?

[nemanja-boric-sociomantic]

Yes. But I also think this should work as well:

SOME_PATH/library-name.so=/usr/lib/library-name.so

[nemanja-boric-sociomantic]

I got distracted yesterday, I'll try to figure out tomorrow what's going on, if you're not faster (please CC me on that PR if you are).

[jordansissel]

@nemanja-boric-sociomantic +1 your suggestion as well.

I think the result is that a file and a symlink should be handled the same:

• path/name=destination/ results in destination/name
• path/name=destination results in destination

[nemanja-boric-sociomantic]

Yes, I've tried to achieve that through https://github.com/jordansissel/fpm/pull/1253, but it may introduced a bug (although I thought I added a test case for it).

[jordansissel]

I was testing with fpm 1.8.1, oops. Will re-evaluate.

[jordansissel]

Confirmed reproduction:

% ln -s a b
% fpm -s dir -t rpm -n example -f b=/test/; rpm -qlvp example-1.0-1.x86_64.rpm
Invalid package configuration: Cannot package the path './b', does it exist? {:l
evel=>:error}

This only affects symlinks, not files:

% rm b
% touch b
% fpm -s dir -t rpm -n example -f b=/test/; rpm -qlvp example-1.0-1.x86_64.rpm
-rw-rw-r--    1 root    root                        0 Aug  8 02:33 /test/b

[jordansissel]

I think this fails because the way we check if the file exists is by normal stat calls (File.exists? etc) which follows symlinks. What FPM should do is use lstat

[nemanja-boric-sociomantic]

@jordansissel I think this should be it: https://github.com/jordansissel/fpm/pull/1399.

[nemanja-boric-sociomantic]

@andreas-bok-sociomantic confirmed to me (and if he's nice, he'll say it here :-) ) that his problem is indeed fixed.

[jordansissel]

woohoo! :)