Hello Mathias, thank you for going through my packages in-depth.
* The typical pattern for new source packages in Debian is to have an ITP filed, which is then closed on the first upload. Right now you have an ITP that's covering both source packages. I'd suggest modifying the existing ITP you have to be specific to makemkv-oss or makemkv-bin, and then creating a new ITP for the other. Then you can cleanly close an ITP for each new source package.
Got it, I have modified the current ITP for makemkv-oss and created a new one for makemkv-bin. Added the "closes" in bin's changelog as well.
* The changelog entry for a new package should consist solely of a line similar to "Initial release (Closes: #<ITP bug number>)". All the work and changes prior to upload aren't specifically called out in the package's changelog. Also, the version number should always end in "- 1".
This actually came to my attention last week and I fixed my packages accordingly. I uploaded the updated packages to Mentors, but forgot to push the changes to git (they were committed, but I never pushed).
* You may want to consider having two separate git repos for the two different source packages. I realize that they are released in lockstep, but having different repos may make life easier.
Having them in the same repo works well for now because some fixes I make to one apply to the other often so I can commit and push at the same time, but once the packages are more mature and in Debian It'll probably make sense to move to two separate repos.
* You may want to look into setting up/using git-buildpackage(1) (`gbp`), which can help make building packages much easier. Of course, the trade-off is a bit of a learning curve, but I think it's worth it in the long run.
My current setup works well for me, and that looks like it has a learning curve like you mentioned. When I'm more experienced packaging for Debian, I'll look into it. This also connects with having separate repos for makemkv-oss and makemkv-bin.
makemkv-oss specific notes: * d/control: Consider setting the Architecture field for the various lib* binary packages to match that of the makemkv binary package.
The libraries can be used in any architecture. While the main makemkv binary can be compiled for any architecture, it can't be used for much because it depends on makemkvcon that's limited to certain arches. Attempting to build makemkv-oss on an architecture not supported by makemkv just builds the two libraries and nothing else. Is this bad practice? Should I limit the libraries' architectures even though they can be used outside of makemkv on any arch?
* d/makemkv.lintian-overrides: Can probably be deleted. Binaries should have a manpage; sometimes if one doesn't exist as a packager you have to write a basic one. Also, this is one of the things noted in the Reject FAQ for NEW [1], which lists several things that may cause ftpmaster to reject a package. The other override is desktop-entry- lacks-keywords-entry; that can easily be fixed with a simple patch to add some keywords to the .desktop file.
What should I put in the manpage though? There's not really any command line flags that can be used by the program, everything's done in the GUI. I haven't written any manpages before outside of simple programs with easy to document command line usage.
As for the .desktop file, that's now fixed.
* d/README.source: Add this file to describe the issue(s) requiring the shipping of bundled copies of libraries. Right off hand I know about libebml and libmatroska, but there may be others. This informs others who may review/work on the package in the future.
Alright, I've cut down the comment in the unused patch file so now it points to README.source for an explanation of why the patch is not used.
* d/source/metadata: Add this file; see [2] for more information.
Added. I think it was in your original package but I deleted it because from what I read in the DEP it seemed like it was optional for now and this source is a bit trickier than others to document.
* d/watch: Is incorrectly looking at the makemkv-bin source file. Also, add a comment that the URL doesn't change, even though it looks like it might.
Fixed.
makemkv-bin specific notes: * d/copyright: There is an important difference between code that is licensed as "GPL-2" and "GPL-2+" (for example). If a license doesn't have "or any later version" (or similar phrasing), it's incorrect to describe it with a "+" (or vise-versa). Admittedly, this is an issue in my original packaging not getting that correct, but it should be fixed in your packaging work. :)
Fixed.
* d/makemkvcon.lintian-overrides: Same comment as before with binaries needing a manpage to be provided.
Just like the last one, I don't really know what to write for it.
* d/rules: No need to have empty override_* targets.
I needed to stop debhelper from running `make` and `make install` in the source because they caused problems and we're bypassing the source's Makefile. I have added a comment explaining why they're empty.
* d/source/metadata: Add this file.
Fixed.
* d/watch: Similar to before, add a comment about the URL being correct.
Fixed.
* debconf: I added a simple debconf message that's displayed to the user to ensure they are aware of the licensing terms when they first install makemkv-bin. I have pretty much no experience with debconf hooks; there may be better/more correct ways to handle this.
I don't see anything wrong with the current way it's handled; if the message about the license isn't displayed to the user upon installation, then the license has been violated. If anyone has a better method of doing this, I'm all ears.
Phew! That got kind of long, but I hope you find it useful. If you have any questions or a comment doesn't make sense, please let me know. Thanks for working on this!
Definitely useful. I can make a package look good from the outside, but there are always minor details to be improved. Thanks again for your in-depth look into the packages!
-- Ben Westover
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature