Manage installation in lib / lib64 directory about stargate

I fixed another (related?) issue that I think was affecting you(?). Symlinking to $(PREFIX)/bin/stargate would result in sglib not found, because Stargate DAW would try to find the relative path from the symlink and not the target file. Correct me if I am wrong, but I think this was your problem, that my code did not know how to handle being symlink'd.

As far as the lib vs. lib64 thing:
$(PREFIX)/lib/stargate does not have any 64 bit binary files IIRC, it's text Python modules, presets, graphics assets, themes and fonts and maybe a few other random files. I am open to moving it to $(PREFIX)/share instead, but having multiple potential paths is a harder sell because it will be quite messy to maintain.

Is this only because you offer 32 bit packages and want to avoid conflict? But if you are installing Stargate DAW to it's own prefix (/opt/stargate), I don't see why it would matter if the folder was named lib or lib64, since it would be completely contained and isolated within it's own prefix. Help me understand what you need and we will figure out a solution.

[ycollet]

Yes, you're right. There are no binaries in /usr/lib/stargate :)
As far as I can tell, the /usr/lib/stargate content should be better placed in /usr/share/stargate.
The only exception should be for the /usr/lib/stargate/stargate content which should be better in /usr/lib/python3.9/site-packages/ (and no lib64 here because there are no binaries in these directories).
But I totally understand your argument about multiple directories.

The package now works. I need to perform some more tests, but now, it starts. It's available on Fedora 33, 34 and 35.

Great, glad to hear it's working. :-)
Be sure to test Fedora35 extra well. I don't know what they did to their PyQt5 package, but it has substantial API differences from any other PyQt5 I have seen. I made a bunch of commits last week to fix issues I found in Fedora 35 beta.

As for the original topic of the thread, I ran this:

$ find /usr/share -name '*.py' | wc -l
779

Seems to be a common practice to put Python scripts and modules in /usr/share when they are not meant to be globally accessible to other Python applications. I've been considering moving everything to /usr/share for a while, my concern with doing it now is there are at least several people (that I know of) actively packaging Stargate DAW, and I suspect it would require every single one of them to change their packaging. I might do this later once things settle down.

Some research did not yield any kind of standard for where to put Python modules that should NOT be available system wide. /usr/share seems to be the place.

Update, expanding the query to be more inclusive:

$ find /usr/share \
  -name '*.py' -or -name '*.lua' -or -name '*.rb' -or \
  -name '*.pl' -or -name '*.pm' -or -name '*.sh' | wc -l
2442

That's a lot of scripts

[ycollet]

So, OK for me. I thought there was some kind of standards for python package installation. But you're right, there must be a difference between package available for other applications and private python libraries. Your proposal is totally fine for me.

BTW, if you have any interest in adding any of your Stargate DAW packages into the main Fedora repos, you are welcome to do so. I would like for Stargate DAW to be in Fedora, Debian/Ubuntu and Arch at a minimum. I am hoping to find others who are interested in being distro package maintainers, in the interest of freeing up my time to focus on developing features and fixing bugs.

Files in $(PREFIX)/lib were moved to $(PREFIX)/share

[ycollet]

Thanks a lot, I will update my spec file for the next release !

See also the latest update in #19 , I made a number of other significant changes to allow internet-less builds without vendored dependencies.

[ycollet]

Thanks, I will clean-up the sed things I added to disable this automatic install :)