Debian packaging

[mjtorn]

After #56 is accepted, this would be nice. It cleans up the Debian packaging quite a lot!

It also splits the binaries into razercfg and qrazercfg, so that the qrazercfg can actually depend on python3-pyside.

[mjtorn]

This might not work without an icon in place. Have to go afk and not care for a while, but I think the core concept here is sound.

[mbuesch]

Looks nice. What's the purpose/advantage of the soversion? Is it possible to do this without an icon? If so, please do that. Also, can you point me to some documentation about the install file format?

All in all it looks pretty good. Please rebase this on master, so the extra commits that already are upstream go away.

[mjtorn]

What's the purpose/advantage of the soversion?

I got it somewhere that all library interfaces/APIs should be versioned. Maybe this isn't released yet and the library API is subject to change, but I saw no harm in preparing for it.

Is it possible to do this without an icon? If so, please do that.

Why of course. Removed the icon installation from debian/qrazercfg.install

Also, can you point me to some documentation about the install file format?

https://www.debian.org/doc/manuals/maint-guide/dother.en.html#install

You may notice that it applies to files that aren't installed by make install. The .desktop file and qrazercfg do get installed with make install for me, but it's as if dh_install doesn't know how to track them, for some reason.

It's also a good idea to use --fail-missing when building, ie. make it easier to spot missed files. I was on the fence of whether or not I should push this as well, but came to the conclusion I'll show it and ask for your opinion.

[mbuesch]

Having razerd, razercfg and almost all other files in the install file seems wrong. They are installed via 'make install', so they should automatically appear in the package. There must be something else wrong with the package scripts.

[mjtorn]

There must be something else wrong with the package scripts.

Umm, on second thought, of course this is how it works. I mean, from make install's point of view it installs a bunch of files produced by a bunch of source, right? That's what the debhelper follows by default with extra files in debian/install when required.

Now when we're building two packages (or more), how would the debhelper know how to divide the files? Like how does it know which output file belongs to which .deb file without us telling it?

Don't think it's broken, I just didn't think it through before saying "for some reason".

[mbuesch]

Ok, well.

I'm still wondering what the purpose of the Debian scripts is anyway. Is somebody going to submit this to Debian? (I'm not). Otherwise this is pretty wasted effort. Nobody will build the package. I would like to see the package in Debian, but the Debian process (and its package format!) seems so overly complex that I'm simply not going to do that.

[mbuesch]

Hell, I reverted this again. (Yes, my fault for not running the build tests before pushing).

This does not build. And it can't! usr/lib/python3.4/site-packages/* usr/lib/python3/dist-packages Hardcoding paths or versions cannot work. At all. There may be other issues. I'm just not going to hunt these down.

[mjtorn]

The reason is that I want to install this on SteamOS.

And it can and does build (for me)

running install
running build
running build_py
running build_scripts
running install_lib
creating /home/mjt/src/git_checkouts/razer/debian/tmp/usr/lib/python3.4
creating /home/mjt/src/git_checkouts/razer/debian/tmp/usr/lib/python3.4/site-packages
creating /home/mjt/src/git_checkouts/razer/debian/tmp/usr/lib/python3.4/site-packages/pyrazer
copying build/lib/pyrazer/__init__.py -> /home/mjt/src/git_checkouts/razer/debian/tmp/usr/lib/python3.4/site-packages/pyrazer
copying build/lib/pyrazer/main.py -> /home/mjt/src/git_checkouts/razer/debian/tmp/usr/lib/python3.4/site-packages/pyrazer
byte-compiling /home/mjt/src/git_checkouts/razer/debian/tmp/usr/lib/python3.4/site-packages/pyrazer/__init__.py to __init__.cpython-34.pyc
byte-compiling /home/mjt/src/git_checkouts/razer/debian/tmp/usr/lib/python3.4/site-packages/pyrazer/main.py to main.cpython-34.pyc
running install_scripts
copying build/scripts-3.4/razercfg -> /home/mjt/src/git_checkouts/razer/debian/tmp/usr/bin
copying build/scripts-3.4/qrazercfg -> /home/mjt/src/git_checkouts/razer/debian/tmp/usr/bin
changing mode of /home/mjt/src/git_checkouts/razer/debian/tmp/usr/bin/razercfg to 755
changing mode of /home/mjt/src/git_checkouts/razer/debian/tmp/usr/bin/qrazercfg to 755
running install_egg_info
Writing /home/mjt/src/git_checkouts/razer/debian/tmp/usr/lib/python3.4/site-packages/razercfg-0.33-py3.4.egg-info
-- Installing: /home/mjt/src/git_checkouts/razer/debian/tmp/usr/bin/razer-gamewrapper
make[1]: Leaving directory '/home/mjt/src/git_checkouts/razer/obj-x86_64-linux-gnu'
   debian/rules override_dh_install
make[1]: Entering directory '/home/mjt/src/git_checkouts/razer'
dh_install --fail-missing
make[1]: Leaving directory '/home/mjt/src/git_checkouts/razer'
   dh_installdocs
   dh_installchangelogs
   dh_systemd_enable
   dh_python3
I: dh_python3 fs:375: renaming razercfg-0.33-py3.4.egg-info to razercfg-0.33.egg-info
   debian/rules override_dh_installinit
make[1]: Entering directory '/home/mjt/src/git_checkouts/razer'
dh_installinit --name=razerd
make[1]: Leaving directory '/home/mjt/src/git_checkouts/razer'
   dh_systemd_start
   dh_perl
   dh_link
   dh_compress
   dh_fixperms
   dh_strip
   dh_makeshlibs
   dh_shlibdeps
   dh_installdeb
   dh_gencontrol
dpkg-gencontrol: warning: package qrazercfg: unused substitution variable ${python3:Depends}
   dh_md5sums
   dh_builddeb
dpkg-deb: building package `razercfg' in `../razercfg_0.33_amd64.deb'.
dpkg-deb: building package `qrazercfg' in `../qrazercfg_0.33_amd64.deb'.
 dpkg-genchanges  >../razercfg_0.33_amd64.changes
dpkg-genchanges: including full source code in upload
 dpkg-source --after-build razer
dpkg-buildpackage: full upload; Debian-native package (full source is included)
dpkg-buildpackage -uc -us  8.95s user 1.14s system 95% cpu 10.518 total

Do you happen to have failure output on you?

As for hardcoding paths - yeah, I should've said usr/lib/python3*/site-packages/*, thanks! It's not a very clean solution either, but that's life. Force-pushed now.

There's surprisingly little on this topic online or in mandh_python3 that would apply to this case, almost as if the source tree layout here is not very standard. There is something called a .pyinstall file, but I couldn't find any notes on version-independence in it and it doesn't seem to offer any value in this case either way.

I checked around in a couple of Python packages from Debian and they tend not to be monorepos shipping libraries and stuff from the same source package; the closest I got was psycopg2 which builds for different versions and does py_libdir = /usr/lib/python$(subst python,,$(1))/site-packages in debian/rules and seems to work automagically.

In summary I think the Python pieces would have to be their own package so Debian would figure out where the files are going, in the vein of having a source layout that works with only make install.

I'll run this by someone who might have more on the matter, but in the mean time I'd like to see how building the package failed for you because I obviously built it a ton of times before pushing your way.

[mbuesch]

Well, as I said, it failed due to the hard coded Python path. I didn't investigate further on this, because there was no obvious fix for this (Changing the hardcoded path would not improve the over all situation). So I gave up and reverted it.

If you have a new version of this that I should try, please send this based on current master (I cherry picked some of the soversion and uninstall.sh changes already). Maybe open a new pull request, because this is closed already.