Add debian packaging information to the repository

[cweagans]

Referencing #652 (comment)

@viccuad already has this information prepared for upstream Debian inclusion, but we should put the packaging information in the repo here so that it's tracked and so that contributors can submit pull requests.

@viccuad Can you please clarify how upgrades will work via the Debian package repositories? If we're locked into whatever release initially goes in, I want to make sure that release is basically 1.0.0 (as opposed to 0.1.0 or some other kind of pre-release version)

[viccuad]

Current status of the Debian package:

Almost done, waiting for #92 to be fixed, and I need to use the new flags implemented in #580 :).
Also, it would be nice to have git tags and/or tar.gz releases.

About including debian packaging info in the repos:

I (as Debian's package maintainer for Universal-ctags) don't need (nor desire) to have the debian folder included in the repo, as I will not use it (the Debian packaging tools delete upstream's debian folders and don't use them). Also, Debian (as many distros) mirrors the source code in their own git repo/ftp, since that allows distros to provide FOSS projects even if upstream people dissapear. Because of that, it's bound to get out of sync with the Debian mirror/git repo.

Now, if you as upstream intend to make your own unofficial .debs, then of course you are welcome to help yourself using the official Debian packaging info folder :). But in that case, please be aware that you will need to act as distro maintainer (be up to date on the developings of the distro, dependencies, etc) and that you will lose some Debian goodies (quality assurance, CI, bug testing, reproducible build checking, ~30 architecture builds, etc).

Questions and answers:

@cweagans said:

Can you please clarify how upgrades will work via the Debian package repositories? If we're locked into whatever release initially goes in, I want to make sure that release is basically 1.0.0 (as opposed to 0.1.0 or some other kind of pre-release version)

You will not be locked on any release :). Debian Unstable and Debian Testing are rolling releases, so they will always enjoy new versions.

@cweagans said (in other issue):

What does the update process for an official debian package look like?

This is the normal scheme:

There exist 3 Debian distributions: Debian Stable, Debian Testing, and Debian Unstable, each of one more faster updating than the other:

1. Upstream publishes a release (by git tags and/or a tar.gz). Yay! Congratulations :)
2. Debian package maintainer gets automatically notified thanks to the debian/watch file and Debian scrappers.
3. Debian package maintainer merges the new version, sees if there are any quirks to be fixed, tries to fix them by making patches, sends those patches upstream and/or patches the Debian version meanwhile.
4. Right following to that, uploads the new version to the Debian FTP repos, normally Debian Unstable.
5. Debian Unstable users can apt-get it, yay! :)
6. If in 5/10 days (configurable) that version hasn't received any Release Critical bugs, it automatically gets uploaded to Debian Testing. Debian Testing users can apt-get it, yay! :)
7. Every 2 years more or less, there's a Debian release, which consists on taking a snapshot of the state of Debian Testing, and freezing those packages, which will only receive bugfixes (as new versions always add new bugs). You can install new versions of selected packages in Stable by using Debian Backports, though.

Also, Debian Experimental exists: it normally contains, well, experimental versions, to be used in conjuction with Debian Testing and/or Unstable (eg: tmux, notice the Accepted tmux 2.1~git20151017-1 (source) into experimental)

In parallel to all of that, twice a year Ubuntu takes a snapshot of Debian Unstable (with a couple of touches) and calls that an Ubuntu release. Among other Debian derivatives.

If you want to learn more about how Debian works, don't hesistate to come by the ircs (#debian, #debian-next on oftc.net) or have a look here and here for example.

@vhda said (in other issue):

@viccuad would you be willing to create a PR (at the time you find appropriate) to have the debian folder merged into our repository?

Let me fix the quirks already there so there's a working Debian package that doesn't need preinstall/postremove hooks to clean changed config folders (I don't want to package it and do a half-job or not care about quality), and I would be happy to create a PR to include the debian folder in this repo if that's what Universal-ctags desires (but please, take into consideration what I have said before).

[cweagans]

Thanks for the very detailed information! This is all good stuff to know about.

I was under the impression that we needed to include the debian packaging scripts in the repo, but if that's not the case, I'm definitely okay leaving it out, especially given the benefits that come from letting Debian do it's own thing (reproducible builds and all that). @vhda - that okay? One less thing for us to maintain.

Also, Debian (as many distros) mirrors the source code in their own git repo/ftp, since that allows distros to provide FOSS projects even if upstream people dissapear.

Does that mirror automatically update whenever we commit something to this repo? Happy to set up a web hook or something for you if that would help.

Re debian release process (last question, I promise):

If we are alerted to some kind of security bug or something, is there a process for getting a patch to fix that into Debian Stable, rather than waiting some number of years to it to eventually trickle down? I see that Debian Stable allows for bug fixes, but I'm not clear on how they will get from this github repo to the package in Debian Stable.

[viccuad]

Does that mirror automatically update whenever we commit something to this repo? Happy to set up a web hook or something for you if that would help.

We can manually do a git pull at any time, or get it automatically updated with tags. Since the Debian packages are going to track your (upstream) releases, I don't really see a need for automatically update for every commit. If you want faster moving versions, then, release early release often they say :P.

If we are alerted to some kind of security bug or something, is there a process for getting a patch to fix that into Debian Stable, rather than waiting some number of years to it to eventually trickle down? I see that Debian Stable allows for bug fixes, but I'm not clear on how they will get from this github repo to the package in Debian Stable.

Yes, of course, bug fixes get backported to the Stable versions (that's my job): when we all notice a security bug, we (normally you because you know the codebase better) implement a fix, you ship your version, and I backport the fix to Stable.

Normally a Debian foobar package (or other distro packages) have the following version numbering/naming:

  pkgname-upstreamversion-distroversion   ( eg: foobar-3.4-3 )

In the specific case of Debian Stable, the bugfixes (applied by me) would bump the distroversion only.

[cweagans]

Closing this, as there's nothing for us to do here. I'll make a note to update this issue when we have our release.

[TomRoche]

What is the status of the Universal Ctags Debian packaging? As of 0200 UTC 5 Oct 2016, when I search packages.debian.org on ctags, I see only 2011 builds of Exuberant. When I search on universal, I don't see anything tag-related. Am I missing something?

[viccuad]

Hi, I'm the current one listed on the ITP (Intend To Package) Debian bug for universal-ctags, which I opened with the intention to have universal-ctags be my first maintainership of a package in Debian.

In that moment, I stated in this message my desire to get a 1.0 release and have some issues resolved before starting maintaining universal-ctags,.

In the meanwhile, I have started maintaining several packages in Debian, and also have moved to Emacs (for which Global meets my needs), so I have to say that sadly I'm stepping down from making the legwork to have universal-ctags included in Debian; I would not have the time nor the will for it.

I will take myself out of the Debian's ITP (Intend To Package) bug open for universal-ctags, and put it back to a RFP (Request For Packaging), for someone to grab. I would be glad to give any pointers to anybody that wishes to maintain a Debian universal-ctags package, and I would love to see somebody to step in :).

[ardumont]

Hello,

I would be glad to give any pointers to anybody that wishes to maintain a Debian universal-ctags package, and I would love to see somebody to step in :).

@viccuad step in :D

In that moment, I stated in this message my desire to get a 1.0 release and have some issues resolved before starting maintaining universal-ctags,.

Well, as a first approximation, using it as is is ok with me :D

I will take myself out of the Debian's ITP (Intend To Package) bug open for universal-ctags, and put it back to a RFP (Request For Packaging), for someone to grab.

For now, i need to package it for the Software Heritage project.
And if it's all good, it'd be worth the effort to push it all the way to debian and i'll do it.

My alioth nick is ardumont-guest (i have packaged some python ones).

For the sake of not duplicating efforts, do you have any available repository from where i could continue your initial work?

Thanks in advance

Cheers,

[viccuad]

@viccuad step in :D

That makes me happy! :)

For the sake of not duplicating efforts, do you have any available repository from where i could continue your initial work?

I forgot to attach the status of the package when I left the ITP, I
have done it now :)

[ardumont]

I forgot to attach the status of the package when I left the ITP, I
have done it now :)

Thanks, I'll merge in your work in mine :D
(I mostly work with the rules so far and within it not the doc part)

Cheers,

[ardumont]

FWIW, work in progress is https://github.com/ardumont/universal-ctags

(It's WIP so the master branch will get rewritten.)

[sim590]

@ardumont. I see you have taken responsability of the debian package. What's the status? I know that it is not yet either in testing or unstable. Is there a package source I can safely build myself in the meantime?

[ardumont]

Hello,

What's the status?

I successfully built and deployed a version (from end of october 2016, ardumont/universal-ctags@7859817).
This is from the current master branch of my fork.

Note: Technically i deployed the package built from 'swh' branch which is one commit more from the master one. (for detail: ardumont/universal-ctags@66c5a95).

But for building, using the master one is sufficient.

I know that it is not yet either in testing or unstable.

Indeed.
I did not yet make the time to push it towards Debian.

Is there a package source I can safely build myself in the meantime?

Well, you could build from my fork from the master branch using gbp buildpackage.
Like i said, it worked at the time.

I did not check it still builds though...
Well, scratch that, i did with:

git clone git@github.com:ardumont/universal-ctags.git
git checkout master
# if not installed (note that i'm on testing and i needed it for jessie).
# sudo apt install cowbuilder; git-pbuilder create
gbp buildpackage --git-pbuilder

And it's still ok.

Cheers,

[jcharaoui]

Just for the record, universal-ctags is now part of the Debian package archive. Congrats!

[masatake]

Thank you.

I tried it.
I have two comments.
It seems that the man pages are not included. Though the pages are written in progress, they will be useful (even for me).
libxml2 is not linked. If it is linked, ctags can handle more xml based languages.

[hnakamur]

Hello, I just built a deb package for Ubuntu 18.04 LTS based on the Debian universal-ctags package.

• my PPA (Personal Package Archives) for universal-ctags
• my deb source package for universal-ctags

I made three modifications:

• included the man pages and also add ctags.1.gz to update-alternatives.
• linked with libxml2, libjansson, libseccomp, libyaml, and libaspell.
• add a patch for skipping one test: Tmain parser-own-fields stdout comparison (This is needed to avoid the following diff which happens only on the Ubuntu PPA build. This diff does not happen on my local build using pbuilder.).

--- /<<BUILDDIR>>/universal-ctags-0+SNAPSHOT20180606/Tmain/parser-own-fields.d/stdout-actual.txt      2018-06-07 13:20:17.380303536 +0000
+++ ./Tmain/parser-own-fields.d/stdout-expected.txt   2018-06-07 05:45:08.000000000 +0000
@@ -1,0 +2,3 @@
+bar  input.unknown   /^protected func bar(n);$/;"    f   
+baz  input.unknown   /^private func baz(n,...);$/;"  f
+foo  input.unknown   /^public func foo(n, m);$/;"    f   
@@ -2,0 +6,3 @@
+bar  input.unknown   /^protected func bar(n);$/;"    f       signature:(n)
+baz  input.unknown   /^private func baz(n,...);$/;"  f       signature:(n,...)
+foo  input.unknown   /^public func foo(n, m);$/;"    f       signature:(n, m)
@@ -3,0 +10,3 @@
+bar  input.unknown   /^protected func bar(n);$/;"    f       protection:protected
+baz  input.unknown   /^private func baz(n,...);$/;"  f       protection:private
+foo  input.unknown   /^public func foo(n, m);$/;"    f       protection:public
@@ -4,0 +14,3 @@
+bar  input.unknown   /^protected func bar(n);$/;"    f       protection:protected    signature:(n)
+baz  input.unknown   /^private func baz(n,...);$/;"  f       protection:private      signature:(n,...)
+foo  input.unknown   /^public func foo(n, m);$/;"    f       protection:public       signature:(n, m)

[masatake]

@hnakamur, thank you for reporting.

libaspell is not needed for normal users. It is linked for developing ctags itself.
About the failure of Tmain parser-own-fields, could you open a new issue for it?

[hnakamur]

#655 (comment)
My merge requests for adding manpages and adding libxml2 to the official Debian package are now merged.

[masatake]

@hnakamur, thank you.