[Resolvconf-devel] What do we need to do to make the Ubuntu version?

[Sander van Grieken]

On 12/01/2011 12:14 PM, Thomas Hood wrote:
> On Thu, Dec 1, 2011 at 09:01, Sander van Grieken
> <sander at outrightsolutions.nl>  wrote:
>> I have discussed the process with Ubuntu maintainers, and the preference is
>> to do as much as possible in debian. I will test the stuff as is in ubuntu
>> and if we run into an unavoidable delta between ubuntu and debian I will
>> notify Mathieu, he will initiate a merge from the latest debian git, and I
>> will branch of that latest merge, and commit the changes needed in my
>> branch. So for now I will work based from debian git and test against ubuntu
>> bleeding.
>
> I am not sure I understand the plan.  Yes, of course we will minimize
> the differences and do as much as is reasonable in the base (Debian)
> package.  But the current Debian package will certainly not work
> properly on Ubuntu.  The Ubuntu version has to differ from the Debian
> version.
>
> 1. The transition to /run is from /var/run/ and not from
> /lib/init/rw/, so the maintainer scripts have to be patched
> 2. /sbin/resolvconf has to exit if /etc/resolv.conf is not a symlink
> 3. Ubuntu changelog entries have to be added
>
> To make #1 easier I will modify the maintainer scripts to use a
> variable instead of the hard-coded path.  But the Ubuntu patch should
> still change the variable assignment line.
yes.
>
> #2 is the case because some Ubuntu developer in the past thought it
> would be a good idea not to give the administrator the freedom to
> install resolvconf and still use a static /etc/resolv.conf.  (Yes,
> that does make sense.)  Aforementioned Ubuntu developer was concerned
> about misbehaving packages that clobber resolvconf's /etc/resolv.conf
> symlink.  He didn't feel inclined to fix the bugs in the misbehaving
> packages but thought it appropriate to modify resolvconf so that it
> doesn't work at all when a misbehaving package clobbers the symlink.
> How this can be considered an improvement escapes my feeble attempts
> at understanding, but not being an Ubuntu developer I bow to the
> decisions made by Ubuntu developers and carry their mods forward.
Some choices in ubuntu are a mystery, yes..
>
> The procedure you propose (merging Debian changes into the Ubuntu
> version, then hacking the latter) sounds unnecessarily complex.
That's how ubuntu handles it. Besides, merging debian resolvconf into 
ubuntu resolvconf doesn't erase all ubuntu customisations.. The merge 
might not be straightforward though, because of merge conflicts. I am 
not 'hacking' the latter, merely applying the delta needed to ubuntify.

#3 is handled for each and every merge from debian, by the maintainer. I 
was told not to worry about it.

>
> Here's what I propose.
>
> In a few weeks we simulataneously release Debian resolvconf 1.63 and
> Ubuntu resolvconf 1.63ubuntu1.  The Debian version will include
> changes made to minimize the size of the Ubuntu patch.  (I have just
> made one change in git, for example: I bumped the version of the
> dependency on initscripts to 2.88dsf-13.10, the version of the package
> in oneiric.)
>
> In the meantime I will create 1.62ubuntuX packages and upload them to
> my PPA: ppa:jdthood/resolvconf.  We invite people to test these
> packages and fix bugs in them before going ahead with the 1.63
> release.
>
> Finally Marco releases from git and we mail a patch to Mathieu for the
> corresponding Ubuntu version.  He can see to it that 1.63+patch gets
> imported into Ubuntu's SCM.
So how is this different from my proposal? you only move the 
ubuntu-debian delta branch from launchpad-bzr to debian-git.

Sander