Skip to content

Sync debian/* with Debian packaging on Debian Salsa #364

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 2 commits into from
Feb 11, 2020
Merged

Sync debian/* with Debian packaging on Debian Salsa #364

merged 2 commits into from
Feb 11, 2020

Conversation

anthonyfok
Copy link
Contributor

Hi @luziferius,

@anthonyfok If there is anything we can adjust on our side to bring our debian control files in line with the ones used by the Debian project, please say so.

Thank you for your very kind gesture. Your updates to debian/* have been really great! Indeed, I borrowed heavily from your effort in the recent Debian package update. This pull request synchronizes the relatively minor changes that I made.

This will reduce the patch sizes on your side...

About "reduce the patch sizes on [debian's] side", it was true with the Debian source format 1.0 where debian/* files get stored in a .diff.gz file, but since the migration to Debian source format 3.0 (quilt), debian/* files are now stored in a .debian.tar.xz

As for upstream source including the debian/ directory, actually, Debian guidelines suggest not including it at all. At https://wiki.debian.org/UpstreamGuide#Initial_Packaging, it is written:

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. Keeping it only in your VCS repository is usually a much saner default if it lives in a specific packaging branch, which mimics what Debian package maintainers do using git-buildpackage. Though leaving the debian folder in the normal branch can also interfere if the package maintainer is using an upstream git packaging workflow (for example: git tag based git-buildpackage workflow).

That said, your current debian folder does not interfere with our current "tarball-based git-buildpackage workflow"; and git-buildpackage simply discards the debian/ directory from the upstream tarball, and instead unpacks .debian.tar.xz into debian/. Also, given the rich history of AutoKey's own Debian packaging, especially a very interesting debian/changelog that goes all the way back to 2008, over 12 years ago, that I thought it is worthwhile to keep it going in your upstream source. :-)

... and increase the packaging quality for everyone.

Debian package uploaded to debian.org is the single source of Debian derivatives including Ubuntu, thus keeping https://salsa.debian.org/python-team/applications/autokey up-to-date is the best way to do so. Unfortunately, that had not happened for Debian's autokey package in the past few years, so the various Ubuntu PPAs has kept AutoKey up-to-date for at least some Ubuntu users.

Hope the situation will improve now that autokey is maintained by the Debian Python Applications Packaging Team. :-D

@anthonyfok
Sychronize Debian packaging updates on Debian Salsa
91307b2 
at https://salsa.debian.org/python-team/applications/autokey

Main changes are:

- debian/autokey-common.postinst, debian/autokey-common.prerm:
    Remove these empty scripts which were created solely to workaround
    https://bugs.debian.org/623163 before the switch from svn-buildpackage
    to git-buildpackage.
- debian/clean: Clean up lib/autokey/qtui/resources/icons/ too
- debian/control:
  * Process with "cme fix dpkg", which reorganizes the fields order,
    bumps the Standards-Version to 4.5.0, updates debhelper dependency to
    "Build-Depends: debhelper-compat (= 12)", and remove Breaks and Replaces
    fields which listed package versions older than "oldoldstable" and
    thus obsolete
  * Process with "wrap-and-sort -a" to sort the dependency list in
    alphabetical order
  * Set Maintainer field to Debian’s "Python Applications Packaging Team"
- debian/copyright: Acknowledge other main authors over the years
    besides Chris Dekter, namely Sam Peterson (2008, the original author),
    GuoCi (2014-2016, Python 3 port), Troy C. (2016-2018)
    and Thomas Hess (2017-)
- debian/docs: Unlist LICENSE to remove Lintian notice "I: autokey-common:
    extra-license-file usr/share/doc/autokey-common/LICENSE.gz"
@anthonyfok
debian/changelog: Restore entries created by Sam Peterson
796f65b 
from http://autokey.googlecode.com/svn/trunk@13 (git commit d8f3ebd)
so that his work on Debian packaging back in February 2018 is not hidden.
@luziferius
Copy link
Contributor

Ah thanks for the clarification. So you always use a fully independent set of control files, even if the upstream project provides a set. I assumed you actually maintain a set of patches and apply that on top of upstreams debian control files. Then my assertions were partially invalid.

And another thank you for coming back and contributing back your changes to the packaging control files.

I didn’t know about some of the nuances you added, like debian/clean. So this is a valuable resource and should help us providing better packages to our users using Debian derivates.

@luziferius luziferius merged commit 14cbb12 into autokey:master Feb 11, 2020
@anthonyfok
Copy link
Contributor Author

Ah thanks for the clarification. So you always use a fully independent set of control files, even if the upstream project provides a set. I assumed you actually maintain a set of patches and apply that on top of upstreams debian control files. Then my assertions were partially invalid.

You assertions would have been entirely correct if we were still using Debian source format 1.0. It turned out, however, it was sometimes difficult to override upstream provided debian/* files when the necessity arose, due to the nature of diff/patch files, and it was very difficult to add a binary file into debian/ too, so those were some of the impetus for eventually coming up with a new source format.

And another thank you for coming back and contributing back your changes to the packaging control files.

I didn’t know about some of the nuances you added, like debian/clean. So this is a valuable resource and should help us providing better packages to our users using Debian derivates.

Actually, thanks to @troxor for starting the debian/clean in the first place! This file is more for the convenience of Debian developers and other .deb builders so they don't have to clean up these stray files manually between manual test builds. It would actually be ideal for the upstream Makefile or setup.py to be able to clean these files, though admittedly I don't know Python setup.py files well enough to do it there, and debian/clean is a quick and easy way around it, haha!

Thanks again!

Cheers,
Anthony

@anthonyfok anthonyfok mentioned this pull request Feb 21, 2020
Merged
@BlueDrink9
Copy link
Collaborator

@anthonyfok are you still available to help with debian releases? We have just had a major update

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@anthonyfok @luziferius @BlueDrink9