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 :-)