Comment 5 for bug 530584

I'd like to write out how I understand this bug, to make sure it is well defined, and then brainstorm some possible fixes.

1) Upstream is imported (as normal), and contains some files that don't end up in the final tarball. These are generally things that are used as templates (such as autogen.sh that I don't really understand, but I assume stuff like Makefile.am and/or Makefile.in also fall into this category.)

2) bzr-builder is used to combine the upstream code with a packaging branch. What I don't really understand here is what gets merged into what. Do you start with a copy of upstream, and call 'bzr merge-upstream' (doesn't make a lot of sense). It seems that you would start with the packaging import, and then call 'bzr merge-upstream'. However, the statement was:
  "- this file isn't distributed into your tarball, so, at first merge-upstream, it will removing it from your packaging branch"
If you started with a packaging branch, then you wouldn't *have* the file in your packaging branch, it would have only been in upstream, and then 'bzr merge-upstream' would presumably just ignore that autogen.sh wasn't present in your local branch.

Or is 'merge-upstream' actually mean 'bring in the latest deb import' and not 'bring in the latest upstream source code'. (yay for having multiple possible definitions of 'upstream' :(

3) At this point, you have a branch which is generally a combination of whatever packaging information, and whatever code has been imported from upstream vcs. You then see that more work has been done in upstream vcs and want to merge it into your packaging branch.

However, upstream vcs also modified the autogen.sh file, which has been deleted in the packaging branch. Which causes a conflict because a file was modified which is now deleted.

So far I think I have a handle on it, though some of the particulars of (2) are hazy.

Here are some more issues:

a) It seems possible to create a per-file merge hook that could say "deleted files supersede". So any time you went to merge content into a deleted file, it would just ignore it, and say "nope, I want that file gone, don't merge any new changes".

The only questions in my mind are how to configure it to know when it is actually active.

  i) always (seems risky if you are switching between projects)
  ii) By path/locations.conf (so whenever I'm working on these projects, deletes supersede, but over here they
      conflict as expected, so I don't accidentally lose bugfixes when code gets moved around.)
  iii) By explicit enumeration in something like .bzr-meta/delete-files
       Instead of running just 'bzr rm autogen.sh', you would then run 'bzr force-deleted-file autogen.sh'
       And bzr-builder could automatically inject that sort of thing if it wanted to.

b) If upstream changes autogen.sh, won't that chain down to something that *should* change in the packaging? Using what I know, if Makefile.am was changed to include a new source file, that would end up touching Makefile.in, and then finally Makefile. And while Makefile.am is not in the tarball, I think Makefile.in would be (which is then ./configure-ed into becoming the Makefile used to build the binary.)

It seems to me that blindly ignoring changes to the base files is quite a bad thing to do. If the standard procedure is to merge the upstream source tree, and then merge in the latest tarball (which would have the changes to the built-products), then it isn't terrible.

c) It seems to me that we should just make it easier to resolve these conflicts, rather than try to pretend that they don't exist.

That said, I'd really like to understand what the problem is from the DX team, so that we can give them a good experience.