Add Debian packaging

[Malizor]

I don't know if it is of any interest to you, but just in case here is what's required for a basic Debian packaging.
My name and email (in debian/changelog, debian/control and debian/copyright) can be reassigned to you if you prefer.

[palemieux]

@Malizor Great. Can you indicate what needs to maintained over time to keep the Debian packaging up-to-date? Will I be able to bug you? :)

[Malizor]

@palemieux Oh, it's mostly adding a new entry in debian/changelog when there is a release (on debian you can use dch -i to automate part of it).

There are specific constraints for version numbers in Debian, for example '1.0.8a2-1' is considered superior to '1.0.8-1'.
That's why I pushed an update to make it '1.0.8~a2-1' which is inferior, as intended.

Otherwise, there should be next to no maintenance on other files. But feel free to ping me if needed :)

[palemieux]

@Malizor Stupid question: the UpstreamGuide states that:

Some projects include a rough /debian directory among source files to ease bleeding-edge package compilation and installation on Debian (and derived) systems. While this is a good effort, it is better to leave it out of the final tarball as it can interfere with debian's own packaging effort.

Is there a reason ttconv would diverge from this recommendation?

Just curious since I have used Debian packaging for decades, but had never looked under the covers until today.

[Malizor]

@palemieux The proper solution, if you want ttconv to be included in official Debian repositories is indeed to exclude the debian folder from release tarballs.
Currently I think you let Github generate source archives automatically after tagging. So it includes everything (including dotfiles which are of no use in an actual release tarball by the way).

I think this answer sums-it up well:

you're expected to attach one or more assets to the release - which means preparing the packages yourself (or using a build/release script) and attaching them either via the GitHub API or manually from the release creation webpage.

Eg. you could publish the result of python3 setup.py sdist, after adding a MANIFEST.in file to ensure doc and scripts folders are included but the debian folder is left out.
If you feel extra geeky, you can also GPG sign the resulting tarball.

So, to sum-up, the merged debian folder would indeed be used for snapshots or "unofficial" Debian packaging. But for ttconv to be accepted in official Debian, it would be better to provide "curated" release archives anyway, which should not contain the debian folder.

[palemieux]

@Malizor how does including the debian folder make it easier for snapshots? This not a leading question, just curious. Understood that the same folder should not be included in releases.

[Malizor]

@palemieux : With the commited debian folder, snapshots can be generated just by running debuild -b from the repository root.
Well, you could even publish the resulting .deb (which appears in the parent folder) as a release asset :)