Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Copy of symlink to packing staging dir in v1.9.x #1395

Closed
andreas-bok-sociomantic opened this issue Aug 6, 2017 · 16 comments · Fixed by #1399

Comments

@andreas-bok-sociomantic
Copy link

@andreas-bok-sociomantic andreas-bok-sociomantic commented Aug 6, 2017

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 comment has been minimized.

Copy link
Owner

@jordansissel jordansissel commented Aug 6, 2017

@nemanja-boric-sociomantic

This comment has been minimized.

Copy link
Contributor

@nemanja-boric-sociomantic nemanja-boric-sociomantic commented Aug 7, 2017

I have a feeling this was the PR that affected this: #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

This comment has been minimized.

Copy link
Contributor

@nemanja-boric-sociomantic nemanja-boric-sociomantic commented Aug 7, 2017

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

This comment has been minimized.

Copy link
Contributor

@nemanja-boric-sociomantic nemanja-boric-sociomantic commented Aug 7, 2017

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

This comment has been minimized.

Copy link
Author

@andreas-bok-sociomantic andreas-bok-sociomantic commented Aug 7, 2017

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: sociomantic-tsunami/libdrizzle-redux@4beb5c9
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

This comment has been minimized.

Copy link
Owner

@jordansissel jordansissel commented Aug 8, 2017

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

This comment has been minimized.

Copy link
Contributor

@nemanja-boric-sociomantic nemanja-boric-sociomantic commented Aug 8, 2017

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

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

@nemanja-boric-sociomantic

This comment has been minimized.

Copy link
Contributor

@nemanja-boric-sociomantic nemanja-boric-sociomantic commented Aug 8, 2017

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

This comment has been minimized.

Copy link
Owner

@jordansissel jordansissel commented Aug 8, 2017

@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

This comment has been minimized.

Copy link
Contributor

@nemanja-boric-sociomantic nemanja-boric-sociomantic commented Aug 8, 2017

Yes, I've tried to achieve that through #1253, but it may introduced a bug (although I thought I added a test case for it).

@jordansissel

This comment has been minimized.

Copy link
Owner

@jordansissel jordansissel commented Aug 8, 2017

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

@jordansissel

This comment has been minimized.

Copy link
Owner

@jordansissel jordansissel commented Aug 8, 2017

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

This comment has been minimized.

Copy link
Owner

@jordansissel jordansissel commented Aug 8, 2017

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 added a commit to nemanja-boric-sociomantic/fpm that referenced this issue Aug 9, 2017
PR jordansissel#1253, while fixed the bug where `source.link=dest/source.link`
resulted in `source.link=dest/source.link/source.link` introduced a bug
where `source=dest/` syntax stopped working for symlinks (it is ok for
files). This is now fixed, as the symlink source now behaves the same as
it would with a single file input. Test case testing this behaviour is
also added.

Fixes jordansissel#1395
@nemanja-boric-sociomantic

This comment has been minimized.

Copy link
Contributor

@nemanja-boric-sociomantic nemanja-boric-sociomantic commented Aug 9, 2017

@jordansissel I think this should be it: #1399.

jordansissel added a commit that referenced this issue Sep 11, 2017
PR #1253, while fixed the bug where `source.link=dest/source.link`
resulted in `source.link=dest/source.link/source.link` introduced a bug
where `source=dest/` syntax stopped working for symlinks (it is ok for
files). This is now fixed, as the symlink source now behaves the same as
it would with a single file input. Test case testing this behaviour is
also added.

Fixes #1395
@nemanja-boric-sociomantic

This comment has been minimized.

Copy link
Contributor

@nemanja-boric-sociomantic nemanja-boric-sociomantic commented Sep 12, 2017

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

@jordansissel

This comment has been minimized.

Copy link
Owner

@jordansissel jordansissel commented Sep 12, 2017

woohoo! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.