Modernize debian packaging

[jwt27]

Here is an attempt to upgrade the Debian package scripts.

Instead of writing the dh_* invocation sequence manually, we can define a single target that invokes dh, and let it run the dh_* subprograms in the order that it wants. Then we can define override_dh_* targets whenever we want it do something different than usual.

Alternatively one could make files such as rhtvision2.2.3.install, rhtvision2.2.3.docs, etc. I think the existing dh_* commands in the rules script are adequate, no need to reinvent the wheel. Those files would also have to be generated at build time to contain the current version number. I see an attempt has previously been made to do that with control.in. Or maybe you still use this to generate the control file?

Some notes:

• I picked compat level 11, this is available on Ubuntu 'bionic'. Debian 'oldstable' has level 12.
• Native-format packages may not contain hyphens in their version numbers. I changed it to a plus sign.
• For cleanup before building the source package, I used git clean. Of course this won't do anything when compiling from a tarball. I hope that's okay.
• Packages are compiled in parallel by default, so doing make -j is not necessary.
• Calling ldconfig in postinst/postrm scripts is no longer necessary. Or, that is what I assumed, since lintian complains about it.
• I removed some remaining dh_make example files, they just add clutter.
• The rules script generated a debianbackup.tar file. I removed this since it seems unnecessary now that we have git.

[set-soft]

Hi @jwt27 !

Native-format packages may not contain hyphens in their version numbers. I changed it to a plus sign.

I don't understand it, the -N is the package iteration number, so 2.2.3-1 is version 2.2.3, first .deb iteration. If something changes in the package, not the source, we'll get 2.2.3-2, etc.

For cleanup before building the source package, I used git clean. Of course this won't do anything when compiling from a tarball. I hope that's okay.

This will force me to always use a fresh cloned repo to create a package. Is true that I don't currently generate packages often, but this seems really annoying, and quite dangerous.

The rules script generated a debianbackup.tar file. I removed this since it seems unnecessary now that we have git.

Ivan added it to make the process simpler. So we can generate a package and continue working, without needing to reconfigure the sources. I think this isn't a big problem, but I must check the consequences.

[jwt27]

Hi @jwt27 !

Native-format packages may not contain hyphens in their version numbers. I changed it to a plus sign.

I don't understand it, the -N is the package iteration number, so 2.2.3-1 is version 2.2.3, first .deb iteration. If something changes in the package, not the source, we'll get 2.2.3-2, etc.

That version format is meant for packages generated from an upstream tarball, where the Debian packaging is done separately ("quilt" format). In a "native" package, the debian directory is part of the repository itself, and in this case it now refuses to build if there are hyphens in the version number.

For cleanup before building the source package, I used git clean. Of course this won't do anything when compiling from a tarball. I hope that's okay.

This will force me to always use a fresh cloned repo to create a package. Is true that I don't currently generate packages often, but this seems really annoying, and quite dangerous.

With -X it only deletes files covered by .gitignore. I assumed that only contains build outputs. If you do have important files in listed .gitignore, then it would be dangerous, true.

The rules script generated a debianbackup.tar file. I removed this since it seems unnecessary now that we have git.

Ivan added it to make the process simpler. So we can generate a package and continue working, without needing to reconfigure the sources. I think this isn't a big problem, but I must check the consequences.

If you want to keep the backups, I'll add it back. It only backed up one file though (linux/libtvfintl.a), which is produced again immediately by building the binary package (but in makes/libtvfintl.a).

[jwt27]

Maybe another idea: you could back up everything removed by git clean, so the source tree will be left exactly as it was before building the Debian package, including build outputs. In that case you could even use git clean -dx to also remove untracked files and directories.

[set-soft]

Hi @jwt27 !

Native-format packages may not contain hyphens in their version numbers. I changed it to a plus sign.

I don't understand it, the -N is the package iteration number, so 2.2.3-1 is version 2.2.3, first .deb iteration. If something changes in the package, not the source, we'll get 2.2.3-2, etc.

That version format is meant for packages generated from an upstream tarball, where the Debian packaging is done separately ("quilt" format). In a "native" package, the debian directory is part of the repository itself, and in this case it now refuses to build if there are hyphens in the version number.

This doesn't make any sense to me. Changes in the packaging can't be reflected in the version itself, this is why Debian packages have "VERSION-PACKAGE_ITERATION". You must find a way to setup the process to keep it this way. How does the tools know if the debian dir is part of the upstream or is just a patch?

For cleanup before building the source package, I used git clean. Of course this won't do anything when compiling from a tarball. I hope that's okay.

This will force me to always use a fresh cloned repo to create a package. Is true that I don't currently generate packages often, but this seems really annoying, and quite dangerous.

With -X it only deletes files covered by .gitignore. I assumed that only contains build outputs. If you do have important files in listed .gitignore, then it would be dangerous, true.

Some times I add things like project files in local formats, or caches. So this isn't a good idea.

The rules script generated a debianbackup.tar file. I removed this since it seems unnecessary now that we have git.

Ivan added it to make the process simpler. So we can generate a package and continue working, without needing to reconfigure the sources. I think this isn't a big problem, but I must check the consequences.

If you want to keep the backups, I'll add it back. It only backed up one file though (linux/libtvfintl.a), which is produced again immediately by building the binary package (but in makes/libtvfintl.a).

The .a isn't really important, but we must avoid removing files that aren't regenerated.