[Solved] How to handle (split) packages that share some files?

Soukyuu · 2017-02-10 18:26:31

I'm trying to write a PKGBUILD for a deadbeef plugin of mine.
The problem: deadbeef supports two GUI plugins, GTK2 and GTK3.
This means each plugin has a ddb_pluginclass_pluginname.so (the plugin) and a ddb_pluginclass_pluginname_GTKx.so (the GUI for the respective GTK version).

Now, I have thought of (and seen) two approaches:

Approach one would be to have one PKGBUILD with two split packages in it.
Problems:
- as far as I understand, build() will fail in case either GTK2 or GTK3 is not installed. I tried having a build() for the plugin and build_pkgname() for each of the split packages, but that doesn't seem to work.
- both packages will have to have the plugin.so included, so those who use both GTK2 and GTK3 (say, two separate users) can NOT have both packages installed, as it would conflict because of existing files.

Approach two would be to have completely separate PKGBUILDs, each only compiling either the GTK2 or the GTK3 version. This solves the problem of failing build() mentioned above, but the second problem about existing files is still there.

How is this supposed to be handled? Or am I thinking too much, and should just rely on user using --force in the case they want both the GTK2 and GTK3 version installed?

Last edited by Soukyuu (2017-02-11 14:52:30)

Lone_Wolf · 2017-02-10 20:08:10

and should just rely on user using --force

--force should only be used as avery last resort, never rely on it.

for clarity :
does deadbeef have 3 files for plugins : ddb_pluginclass_pluginname.so , ddb_pluginclass_pluginname_GTK2.so & ddb_pluginclass_pluginname_GTK3.so ?

If that is correct, an approach with 3 split packages should work.

package_so has ddb_pluginclass_pluginname.so

package_GTK2 depends on package_so and installs ddb_pluginclass_pluginname_GTK2.so

package_GTK3 depends on package_so and has ddb_pluginclass_pluginname_GTK3.so

WorMzy · 2017-02-10 21:17:40

To add to what Lone_Wolf described, several packages in the official repositories have "-common" packages for this very reason, e.g. wireshark-common, fuse-common, pyqt5-common. Take a look at these.

Soukyuu · 2017-02-11 14:51:21

Thanks for the input, I guess most of the AUR packages for deadbeef plugins are "broken" in this way, then. And yes, each deadbeef plugin consists of the plugin.so itself plus the gui.so for the specific GUI toolkit.

One of the things I hate about AUR is having to manually resolve dependencies for AUR packages, but I guess the only way to avoid that would be to make a custom repo (or use an AUR helper, but that opens an entirely other can of worms...)

Arch Linux

#1 2017-02-10 18:26:31

[Solved] How to handle (split) packages that share some files?

#2 2017-02-10 20:08:10

Re: [Solved] How to handle (split) packages that share some files?

#3 2017-02-10 21:17:40

Re: [Solved] How to handle (split) packages that share some files?

#4 2017-02-11 14:51:21

Re: [Solved] How to handle (split) packages that share some files?

Board footer