Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Subfolder handling in /usr/lib #305

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.

Sign up for GitHub

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

Jump to bottom
Open
tresf opened this issue Jan 14, 2025 · 2 comments
Open

Subfolder handling in /usr/lib #305

tresf opened this issue Jan 14, 2025 · 2 comments

Comments

@tresf
Copy link

tresf commented Jan 14, 2025 •
edited
Loading

Hi,

I'm migrating a project from linuxdeployqt to linuxdeploy and I'm running into an issue where shared objects are relocated into the root of /usr/lib.

For example, the project expects a plugin in:

  • /usr/lib/myapp/myplugin.so

... but after packaging, the plugin ends up in:

  • /usr/lib/myplugin.so

Naturally, this breaks the historical scanning process for these files in the app. Despite these files being "plugins", they often do rely on bundled libraries, such as fftw3f, or in some cases use Qt libs for UI, so relinking them using linuxdeploy (or some other method) is needed for a portable application.

Previously, I used -executable flag. Starting with linuxdepoy, I've tried both the --executable and the --library flags but I'm struggling to keep the expected layout. Do other project have this problem? If so, how did you work around them?

Link to downstream bug report for context: LMMS/lmms#7252 (comment)
@tresf tresf mentioned this issue Jan 14, 2025
Merged
19 tasks
@messmerd
Copy link

@TheAssassin Any thoughts about this?

I think it's an important feature to have since sometimes manual control over where shared objects are copied is necessary.

When creating Conan packages, for example, Conan's copy function has a keep_path parameter which I believe provides the same kind of functionality @tresf is requesting here. (See: https://docs.conan.io/2/reference/tools/files/basic.html#conan-tools-file-copy)

When Conan's keep_path is True, relative paths from the source folder are kept when copying to the destination folder, but when keep_path is False, it functions similar to how linuxdeploy does today - copying all files to the same destination folder regardless of the subfolder it originated in. By default, Conan's keep_path is True, but in linuxdeploy it would probably need to default to False to avoid breaking backwards compatibility.

@messmerd
Copy link

@TheAssassin Hi, could you please respond to this issue?

The lack of subdirectory preservation is causing us huge headaches over at LMMS and it is forcing us to use ugly hacks that don't fully work.

If you think this feature could be added, or if you know of a solution we haven't thought of, please let us know

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@tresf @messmerd