Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Add debian packaging information to the repository #655
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)
This was referenced
Nov 6, 2015
Current status of the Debian package:
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:
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):
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:
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.
@vhda said (in other issue):
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).
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.
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.
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.
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:
In the specific case of Debian Stable, the bugfixes (applied by me) would bump the distroversion only.
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 :).
@viccuad step in :D
Well, as a first approximation, using it as is is ok with me :D
For now, i need to package it for the Software Heritage project.
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
I successfully built and deployed a version (from end of october 2016, ardumont/universal-ctags@7859817).
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.
Well, you could build from my fork from the master branch using
I did not check it still builds though...
git clone email@example.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.
Hello, I just built a deb package for Ubuntu 18.04 LTS based on the Debian universal-ctags package.
I made three modifications: