including libs in assets vs. system wide include

[dvzrv]

As mentioned at DPF it would be benifical to provide DPF system wide, or alternatively include the desired version in the source release (as part of the assets). This would allow me to ship zam-plugins for Arch Linux

[falkTX]

See my answer in that linked bug report. I do not intend to support this at all, DPF should be included directly as source code and not a system library. Would you install different commits and branches of DPF system wide? Will you fix all plugins to work with a specific DPF version?

It's true the API has not changed much so far, but I cannot promise to keep it that way. And I specially dont want to feel limited on this, by having someone packaging DPF system wide... Debian already includes zam-plugins, and has no issues with including DPF in the source. (they only complained about the custom DSSI and LV2 headers)

[falkTX]

@zamaudio please close this issue, thanks.

[zamaudio]

@dvzrv zam-plugins already has a make dist target that recursively clones the repo and includes the necessary files for a source release. I don't support the source tarball made by Github, that's not supposed to be used and I can't switch it off.

[dvzrv]

@falkTX valid point and thanks for the clarification.

Oh, completely didn't see the package maintainers section. Nevermind the noise! :-)

[dvzrv]

@zamaudio so, just to get this process right: As a packager I'm supposed to

• git clone https://github.com/zamaudio/zam-plugins
• cd zam-plugins
• checkout [tag]
• make dist
• tar xvJf zam-plugins-[tag].tar.xz
• cd zam-plugins-[tag]
• make
• make install

,right?

I have some problems with it on the way though: When doing a

git checkout 3.10
ls -lah
make dist

in the chrooted build environment I get the following:

Note: checking out '3.10'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at a3321af Version 3.10
total 44K
drwxr-xr-x  8 builduser builduser  360 Mar 10 14:32 .
drwxr-xr-x  3 builduser builduser   60 Mar 10 14:32 ..
drwxr-xr-x  2 builduser builduser   60 Mar 10 14:32 bin
-rw-r--r--  1 builduser builduser 1.4K Mar 10 14:32 changelog
-rw-r--r--  1 builduser builduser 3.9K Mar 10 14:32 Dockerfile
drwxr-xr-x  2 builduser builduser   40 Mar 10 14:32 dpf
drwxr-xr-x  8 builduser builduser  260 Mar 10 14:33 .git
-rw-r--r--  1 builduser builduser  134 Mar 10 14:32 .gitignore
-rw-r--r--  1 builduser builduser   66 Mar 10 14:32 .gitmodules
drwxr-xr-x  3 builduser builduser   60 Mar 10 14:32 lib
-rw-r--r--  1 builduser builduser 1.5K Mar 10 14:32 LICENSE
-rw-r--r--  1 builduser builduser 3.0K Mar 10 14:32 Makefile
-rw-r--r--  1 builduser builduser 3.3K Mar 10 14:32 Makefile.mk
drwxr-xr-x 23 builduser builduser  480 Mar 10 14:32 plugins
-rw-r--r--  1 builduser builduser  136 Mar 10 14:32 .plugins.kdev4
-rw-r--r--  1 builduser builduser 1000 Mar 10 14:32 README.md
-rw-r--r--  1 builduser builduser 6.0K Mar 10 14:32 .travis.yml
drwxr-xr-x  2 builduser builduser   60 Mar 10 14:32 widgets
if test -d .git; then \
        git describe > .version; \
fi
cat: .version: No such file or directory
cat: .version: No such file or directory
cd dist; tar -cvzf ../zam-plugins-.tar.gz zam-plugins-
rm -rf dist
/bin/sh: line 0: cd: dist: No such file or directory
tar: zam-plugins-: Cannot stat: No such file or directory
rm -rf dist
mkdir dist
git clone --recursive . dist/zam-plugins-3.10
tar: Exiting with failure status due to previous errors
make: *** [Makefile:97: _dist_gz] Error 2
make: *** Waiting for unfinished jobs....
Cloning into 'dist/zam-plugins-3.10'...
done.
Note: checking out 'a3321af1892a6994d64fb705e48ae8adf8d7df20'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

Submodule 'dpf' (git://github.com/DISTRHO/DPF) registered for path 'dpf'
Cloning into '/build/zam-plugins/src/zam-plugins-3.10/dist/zam-plugins-3.10/dpf'...
Submodule path 'dpf': checked out '279c265361a9da5a1491107585c75284e0dc0e18'
(cd dist/zam-plugins-3.10; git checkout 3.10)
HEAD is now at a3321af Version 3.10
make -C dist/zam-plugins-3.10 plugins .version
make[1]: Entering directory '/build/zam-plugins/src/zam-plugins-3.10/dist/zam-plugins-3.10'
make[1]: Nothing to be done for 'plugins'.
if test -d .git; then \
        git describe > .version; \
fi
make[1]: Leaving directory '/build/zam-plugins/src/zam-plugins-3.10/dist/zam-plugins-3.10'
rm -rf dist/zam-plugins-3.10/.git* \
        dist/zam-plugins-3.10/*/.git*

This is probably due to the fact, that makepkg acts very strictly on how it is executing its several build steps and this seems to clash with how the make targets are executed (note: the make dist works fine, if I do this outside the build environment).

Another problem I currently have with the above process is, that I can not do an automated checksum check on the source tarball this way.

I don't support the source tarball made by Github, that's not supposed to be used and I can't switch it off.

Wouldn't it be possibly for you to supply your own source tarball (based on make dist) as an asset then? At least for Arch I can not just host a source tarball somewhere else and use that then. It would also not be my place to do so.

In any case, in the current state it would not be possible for me to move zam-plugins to Arch Linux' [community] repository (which I intend to). Do you have any recommendations on how to proceed with this?

[zamaudio]

I can't possibly support every distro, besides, I am trying to sell the binaries. I'm not sure what you expect from me. I'm happy to take PRs that make it easier for you to package it, but I'm not going to spend much more time on this.

[dvzrv]

Well, I guess basically I'm asking you to provide the source tarball through github (as an asset), because hosting it anywhere else (aside from your website maybe), would hardly be "upstream".

If you don't want to do that, that's fine too. I've now found a way of checking out the specific tag + updating dpf as a submodule. Once pacman is released in its next version, it can even verify your signed commit with your pgp key.

Please, don't get me wrong: I was just a little puzzled by having the specific make dist target, but not using it for your own assets.

So, all in all, this works for me now! Thanks a lot for the great work!