Re: Quick idea: VCS for cabal-debian → official-debian modifications
Hello,
The only difference between different runs of cabal-debian will be the
debian/control and debian/changelog files -- the rest should be the
same. Since both of these files are machine readable to a useful
degree, you might find it easier to have specialize merged tools
intead of just using diff/diff3/perfect diff/whatever your VCS uses.
To merge the debian/control file you need:
1. the previously generated debian/control (call this A)
2. the hand modified debian/control (call this B)
3. the newly generated debian/control (call this C)
4. a file that contains a merge of the new debian/control and the hand made modifications (call this D)
Then you apply some simple rules for merging the files.
- If a field (such as the long description) is the same in A and C,
then use whatever is in file B. This is based on the assumption
that if the maintainer modified the generated values in A and the
generated values in C are identical, then the maintainer will want
to make the same modifications. The logs should note that previous
changes were reapplied.
- If a field is the same in A and B, then use the generated value C.
Since the maintainer did not make any modifications before, there
are no modifications to apply now. However if 'C' is different than
A/B, then the logs should note that so that the maintainer can see
if they need to make any changes.
- If A, B, and C are unique, you might still be able to merge things,
depending on the field. For example, for build-depends, you can
(using the debian haskell library), calculate which dependencies
the maintaining add/removed/modified between A and B. You can also
calculate what dependencies where added remove automatically
between A and C. And then you can merge those changes in D. This is
imperfect, so the messaging must be clear on what happened and why
so that the maintainer can check that the correct thing happened.
- If A, B, and C are identical, then pick whichever you want :) You
would not want any messaging for this in the default case, because
that would obscure the important messages. Though, it could be
messaged in verbose mode.
Merging the changelog should be trivial. There is code in
Debian.Changes for parsing the debian/changelog. So, merging changes
mostly comes down to making sure that entries with higher version
numbers also have higher date values, etc.
- jeremy
At Thu, 16 Apr 2009 22:03:47 +0000,
Joachim Breitner wrote:
>
> [1 <text/plain; UTF-8 (quoted-printable)>]
> Hi,
>
> an idea just crossed my mind. I hope it doesn’t sound too confused :-)
>
> Shouldn’t it be possible to use have a workflow like this:
> (replace branch by repository if you want to use darcs)
>
> * One a branch for upstream releases
> * Forking off this branch for each version, to store the result of
> running cabal-debian
> * Another branch for the official Debian source package
>
> Then, when a new version is to be packaged, you import it into your VCS,
> create the cabal-debian fork, and merge it into the Debian branch,
> applying all the changes that you need to had to make to get the package
> in a fit-for-Debian shape.
>
> Of course, this would be even better with a small script to automate
> these steps.
>
> And effectively, if people prefer no VCS, it’s close to keeping your
> changes after cabal-debianization in the form of a diff.
>
> I didn’t actually check the output of cabal-debian, but it might need
> some minor tweaks (such as outputting the auto-generated
> build-dependencies on a different physical line of the Depends: field)
> to reduce the risk of merge conflicts.
>
> Greetings,
> Joachim
>
> --
> Joachim "nomeata" Breitner
> Debian Developer
> nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
> JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
> [2 Dies ist ein digital signierter Nachrichtenteil <application/pgp-signature (7bit)>]
>
Reply to: