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

Some resource files in lector/resources/raw/ are installed twice #63

Open
guoyunhe opened this issue Jun 1, 2018 · 3 comments
Open

Comments

@guoyunhe
Copy link
Contributor

guoyunhe commented Jun 1, 2018

For example, lector.desktop and lector.png has been installed in /usr/share but they are also installed in /usr/lib/. (tested with 0.3.1)

@BasioMeusPuga
Copy link
Owner

Yeah. This is probably the result of data_files in setup.py. I don't really see this as a major issue though. Is it causing packaging issues?

@guoyunhe
Copy link
Contributor Author

guoyunhe commented Jun 8, 2018

here will be some warning when building RPM package. But it can be solved by replacing with symlink.

For users, only disadvantage is the waste of disk space.

Maybe you can move these files which are installed in /use/share to a different source folder. Then they will not be installed in /use/lib

@audreytoskin
Copy link
Contributor

audreytoskin commented Jan 13, 2020

I just noticed this issue too. Lector.png gets installed to the hicolors icons directory, lector.desktop is installed to the desktop applications directory, and after pull request #120, the .metainfo.xml file will be installed in /usr/share/metainfo/ (or similar). So I don't think there's any reason keep them in ./lector/resources/raw/, at least.

It's a minor problem, though I might have initially assumed it was an easy fix. Is there something about setup.py that would make this inconvenient? I haven't done many builds or packages in Python, so I'm not too familiar with the gritty details here.

As a packager, having unneeded duplicate files bugs me... but I suppose I probably wouldn't push for it either, if this were going to be a pain in the ass to deal with.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants