[braindump] ppa update discontents

[Scott Kitterman]

On Friday, August 20, 2010 04:47:11 am Martin Pool wrote:
> It can be a bit hard to work out which packaging branch is used for
> the version in our ppa.  Launchpad has a concept of series branches
> for We can have a convention for plugins that we package, but it's
> just a convention and because it's evolved over time it's not always
> consistent.  For instance if Gary has uploaded bzr-gtk -
> 0.99.0-1~hardy4 but it's failing, I can get the source for that
> package and try to fix it, but I can't easily work out what branch
> contains that source.  (Well, I can guess it's one of the recently
> updated branches in <https://code.edge.launchpad.net/bzr-gtk> but it's
> not great.)

I have to deal with some similar problems with the 
https://launchpad.net/~ubuntu-clamav/+archive/ppa - it's relatively empty at 
the moment, but when testing, we provide clamav (and often it's rdepends) all 
the way back to Dapper.

I have a non-UDD workflow that seems like it is worth sharing because if UDD 
could make this easier, it would be a motivator for me to use it.

When I start to backport, I:

grab the source package from the development release (maverick in this 
example)
add a new ~lucid1~ppa1 debian/changelog entry
debuild -S
cd ../
dput clamav-ppa clamav_0.96.1+dfsg-3ubuntu5~lucid1~ppa1_source.changes

Then start the next one.

cd clamav-0.96.1+dfsg
edit debian/changelog to ~karmic1~ppa1
debuild -S
cd ../
dput clamav-ppa clamav_0.96.1+dfsg-3ubuntu5~karmic1~ppa1_source.changes

Then move on to the next.

Jaunty needs a small change in debian/control, so I repeat the above process 
with the addition of changing debian/control and documenting this in the 
changelog.

Hardy gets interesting as there are more changes in debian/control needed as 
well as maintainer script adjustments.  I follow the above process, but I also 
have a patch of the non-changelog diff for Hardy that I apply using patch and a 
standard Hardy changelog entry that I add documenting the changes.  The first 
hunk of the patch for debian/control always fails, so I do that manually.
Then I follow the process and upload.

Dapper is yet another layer of fun for which I have another patch for 
Hardy/Dapper changes and a standard debian/changelog entry.

Eventually, all those build and I (if needed) do the rdepends updates).

Sometimes there are release specific problems that I need to go back and 
address.  To do this, I:

cd to the top of my clamav packaging directory
rm -rf clamav-0.96.1+dfsg (the unpacked source package)
dpkg-source -x clamav_0.96.1+dfsg-3ubuntu5~hardy1~ppa1.dsc (unpack the exact 
version I want)
make additional changes
increment the version in debian/changelog to ~ppa2
debuild -S
cd ../
dput clamav-ppa clamav_0.96.1+dfsg-3ubuntu5~hardy1~ppa2_source.changes

I'm sure it's reasonably clear that this a lot like switching branches, just 
with no VCS in the picture.

If there was a really logical way to keep track of which branch I wanted and 
switch between them intuitively as well as to easily integrate the per-release 
packaging diff when I move to a new version to base the backporting work on, 
then it would be really useful to me as the current method is not precisely 
pain free.

So here's another example use case for you ....

Scott K