Le mardi 29 juin 2010 à 16:16 +0000, John A Meinel a écrit :
> 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.)

Right, this is similar

> 
> 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"

Well, packaging import isn't the first branch created for everything :)
Here, we are in case where dx team is upstream, so we need packaging
branch for cooking things a lot before reaching a state that enables us
to push it to maverick. That's why the way to do this and have upstream
file-ids is to start with bzr branch trunk/ packaging and then, bzr
merge-upstream. If you have better procedure, do not hesitate to state
them here.

> 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' :(

all is related to previous workflow there, due to have upstream using
bzr and needing packaging branch for daily build before it reaches
ubuntu.

> 
> 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.

I think c) for a daily build in hudson should be fine (also, packagers
don't change file outside debian/ as a best practice, we can have just
copying debian/ directory from the recipe rather than merging back…)

> 
> 
> 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.

Do not hesitate if you need more input or feel free to ping me on
IRC : )