A native debian package is a package that doesn't have a -1 version, and for which there is no difference between "upstream" and the "debian" source.

In other words, it means the debian/ directory is shipped directly with the package.

This is pretty much our case.

I think the only reason we have a separate branch for the debian package is because I was lacking clue at the time and was always packaging third party software.

Now, since we are not uploading the debian package to the official debian archives and are maintening the package ourselves, it is perfectly appropriate to make it native.

The main reason for the change would be to make releases simpler (no fiddling around merging branches) *and* allowing to easily build 2.x packages, which is currently hard or near impossible.

Opinions?

I am marking this critical so that we release 1.7 with the new packaging scheme. This also involves updating documentation (and the release process) and jenkins scripts.

Comments

steven jones’s picture

steven jones commented

Makes sense to me, maybe we need sign-off from mig5 too though.

Let me know if the Jenkins stuff is being silly and you need me to look at it/explain it.

anarcat’s picture

anarcat commented

In retrospect I think we should keep the debian version number, but still import the debian/ directory into the main branches.

steven jones’s picture

steven jones commented

Let me know if the Jenkins stuff is being silly and you need me to look at it/explain it.

That sounded really patronising, I just meant that maybe some of the Jenkins stuff isn't as logic/clean as it could be, and it might need a little cleaning up.

anarcat’s picture

anarcat commented

Alright. One of the blockers I have here for the release is the "R debian provision changelog" task. It delegates the job of laying down the debian tags and creating the changelog entry to Jenkins.

I believe this should be done by the release.sh script, so I'll start working on this. Documentation will need to be updated.

anarcat’s picture

anarcat commented

i have started working on the release.sh script. i think it should mostly work and takes care of editing the changelog now.

I have pushed the 2.x branch merged with debian/ upstream. i have built a jenkins job to build packages from that branch.

this merge makes the build scripts incredibly simpler. instead of mucking around with branches, we just git-buildpackage the tree right here and there. it works as long as jenkins checks out the branch as a named branch (just a small setting in the advanced git settings of jenkins).

now I have also worked on an install job that would actually copy those .debs to the rackspace servers and install them with dpkg -i. Unfortunately, that job seems to be completely stalled because rackspace is timing out... i think we can ignore that problem for now and asssume the 2.x packages build properly.

next steps:

1. merge the 2.x debian work back into 1.x
2. test the release.sh script
3. remove the "R release tags" and "R debian provision changelog" jobs that are replaced by release.sh
4. test the release process again

regarding the changes into jenkins, i believe that we (core devs) should be the ones pushing critical stuff in the repositories, not jenkins. so tags should be laid and pushed by real people.

I also feel that official packages should be built, signed and pushed by real people too. now maybe the last bit is where things were getting rough in the release process and why those jenkins jobs were created, I don't know. maybe i am going against the flow here, but it seems to me that automating the release *completely* is a bad idea: it puts too much faith in the security and integrity of jenkins.

nevertheless, I am opened to the idea of automating that part as well, I just feel strange to see packages signed by jenkins in the stable repository.

I am also unclear as to why we need the "clear unstable channel" job.

anarcat’s picture

anarcat commented
Status: Active » Fixed

1. merge the 2.x debian work back into 1.x

done.

2. test the release.sh script

done. it works, but we have a problem, which I think I will describe in the #1439120: Release 1.7 to simplify followup here: really, the deed is done, the debian branch is now deprecated for the 1.7 and 2.x releases.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.