Skip to content
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.

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

Debian packaging #32

Open
wants to merge 10 commits into
base: main
Choose a base branch
from
Open

Debian packaging #32

wants to merge 10 commits into from

Conversation

RogueScholar
Copy link
Contributor

First off, let me say I think you make the best Plasma 5 add-on in the KDE Store 🥇; I'd be crushed if I ever lost the ability to add it to all of my computers.

This PR was born out of my own need to rebuild the deb file available from your PPA against the most recent libqalculate version which I package myself as an enthusiast of the project (available here if you're curious), as a recent release incremented the soname version from libqalculate20 to libqalculate21. In the process of setting up the rebuild I had occasion to flesh out some of your packaging files and orient them towards a more automated workflow, the results of which seemed only fair to share with you in the event you found them useful for your own packaging efforts.

Some notable changes/additions:

  • There were what seemed to be minor inaccuracies in your metadata file which I elected to patch in my package, but if you concur with them should probably be merged upstream.
  • Your copyright file seemed to indicate that you wanted to license your packaging files under GPL-2.0-or-later, which struck me as odd considering you use the MIT License for the underlying codebase. Accepting it prima facie I crafted my revision of your copyright file to declare dual licensing for the packaging (I always use Apache 2.0 for my packaging efforts unless incompatible with the license of previous maintainers), but if again that was more the result of not wanting to dive too deeply into the abyss that is Debian packaging guidelines then that should be changed to Apache-2.0 OR MIT and the GPL2 stanza can be sent promptly to the round file. 😉
  • All of the git-build-package parts operate on the assumption that all of these changes, if elected to be merged upstream, would be kept in their own branch named debian. If you prefer some other arrangement just let me know and I'll correct them accordingly.
  • Some of the commits were nothing more than the product of my own preferred workflow, namely the VisualStudio Code settings and workspace files as well as a global pre-commit hook I have that lints and reformats all CMake files with the help of cmake_format, but I was careful to keep those confined to their own commits in case they weren't to your liking and you preferred to cherry pick only the essential packaging work.
  • The second changelog was merely something I used to aid me in fleshing out your Debian changelog with the project's complete history. I kept it to act as my crib notes in the git-build-package workflow since github_changelog_generator automatically amends new changes to it when I return to package new versions, but as before that was kept as its own commit so that if you see no utility in it, it can easily be cherry-picked/reverted.

That's all that stands out off the top of my head, but of course I'm happy to elaborate on these or any other questions which might arise. Lastly, I had a mind to create a project and a team on Launchpad such that the codebase could be mirrored there in a Bazaar repository which would lend itself most elegantly to a couple source code recipes that would automate building packages for new releases (both of this project and for future Ubuntu releases). How does that idea strike you? If not poorly then would you prefer to create them yourself or shall I? As a joint effort I'd be happy to help out when needed keeping the packaging up-to-date and looking after the recipes, or if you're amenable to the idea but have no interest in being involved that's fine too.

That pretty much wraps it up for me at this point, I hope this PR finds you well and I look forward to your response in due time.

-Peter

@dschopf
Copy link
Owner

dschopf commented Jan 12, 2020

Hi Peter,

thanks a lot for all the effort you have put into this PR. As you may have noticed this was my first Ubuntu package, so the issues you found do not really surprise me. But since you seem to have quite some experience with this process, I would like to ask you some questions before actually merging all your changes.

Where is the debian/ folder usually stored for other open source software, I have never seen the debian folder or a destinct debian branch in any official repository. Is there then a clone into a bzr repo which adds these folders?

How is this debian folder then versioned for the different releases? Is there a separate branch for each release, like disco, eaon, etc.? I now have local folders in a Ubuntu VM to actually build the packages, but I guess there must be a better way to do this.

The idea of the Launchpad project/team looks very appealing, especially when builds can be automated for new releases. For me it's always kind of tedious to update and build all packages manually for every release. While I would not want to be responsible for it, it would be nice to have access and see what is actually needed for setting this up (in case I have more packages in the future).

I will check you commits and maybe cherry-pick some of them into master if you don't mind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants