4

I used uupdate to update a source package from 0.7.0 to 0.7.3. It does this update with patches and I had a few patch rejects. I am unsure what to do next. Do I:

  • edit the old source package (0.7.0) and then re-run uupdate?
  • edit the new source package (0.7.3) and then re-run uupdate?
  • edit the .rej files directly?
  • use a tool such as kdiff3?
  • try something else?

At this point, I'm thinking that the answer is to use a tool which is more along the lines of what I'm familiar with (coming from a Tortoise Merge and clearcase merge background).

I have searched high and low for how people manage patch rejects and I've had no luck, so I will gladly RTFM if you can provide a link to a FM if one exists.

2 Answers 2

3

I agree with @maco on manually resolving the conflict. Seeing the options you give, you probably need to really understand what uupdate does, which is:

  • extract the new tarball in the parent directory ;
  • try to apply the previous diff.gz (unless you're using a v3 (quilt) style) to the new directory.

The patch rejections come from applying this diff.gz to the new directory.

Now to go through your options:

  • edit the old source package => you shouldn't modify the old source package in order to create the new one ;
  • edit the new source package and re-run uupdate => there is no point in doing so, because the patch fails to apply to the new source, and you shouldn't modify the original source (except with patches, which are found in the diff.gz) ;
  • edit the .rej files => the .rej files are here to show you what failed to apply ; editing them won't fix your issue but you should have a look at them to see if the failed changes need to be applied ;
  • use a diff tool => sure, that can be a good idea, (vim -d is your friend) although the .rej files should already give you an idea of what failed to apply. You can also read the previous diff.gz to have an idea of what files it was modifying.

Generally, most of the uupdate conflicts I've met were due to bad packaging in the previous version of the package, namely a diff.gz which modified the source instead of just adding a debian/ directory. This can be checked easily:

zcat ../yourpackagename_0.7.0-1.diff.gz | diffstat

will give you the list of files modified by the previous patch (adapt the file name to your needs). If you find files that are not in the debian/ directory in this list, then your problem is most certainly there. In this case, check what has been changed:

  • In most cases, it is an autotools mess when debuild -S was called: one of the autoconf/automake scripts was modified and this modification won't apply anymore. It is usually safe to drop this change in the new version ;
  • In some other cases, the source code has been patched manually (without using dpatch/simple-patchsys/quilt/whatever else). In this case, check if the patch should still be applied to the new version (read the changelog for example). If it does, then make a clean patch using a proper patch manager. Future packagers will thank you for that :-)
1
  • I think that all of my rejects are the 1st case you stated, remnants of a build. They are all Makefile and config.xxx file changes.
    – mfisch
    Sep 1, 2010 at 2:35
2

I would just manually resolve the conflicts and run debuild -S as usual.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .