[Pkg-xen-devel] git workflow, redux

[Hans van Kranenburg]

On 08/24/2018 08:14 PM, Ian Jackson wrote:
> Hans van Kranenburg writes ("Re: git workflow, redux"):
>> On 08/24/2018 01:27 PM, Ian Jackson wrote:
>>> There is no pre-cooked recipe or tool for converting a packaging-only
>>> style branch to a git-debrebase branch.  And this kind of surgery
>>> involves more a thorough understanding of the gdr branch format than
>>> merely using the tool on an existing branch does.
>>>
>>> If you would like to try it then you're welcome to, but maybe it would
>>> be better for me to do it.  How about I do this today, and push it to
>>> a wip branch on salsa for you and Wolodja to take a look at.
>>
>> Sure.
> 
> I have now done this.  It is in:
>    salsa/diziet/dgit/experimental.draft
> 
> Some notes:
> 
> 1. Bugs in git-debrebase
> 
> This is the first time I have used git-debrebase on a package whose
> patches were in subdirectories.  Evidently it is the first time anyone
> else has, either: git-debrebase had some trouble with that.

Hm, the kernel people also have a whole bunch of subdirectories. Did Ben
not also run into this yet?

https://salsa.debian.org/kernel-team/linux/tree/master/debian/patches

-$ tree -d
.
├── bugfix
│   ├── all
│   ├── alpha
│   ├── arm
│   ├── arm64
│   ├── ia64
│   ├── m68k
│   ├── mips
│   ├── powerpc
│   ├── sparc
│   └── x86
├── debian
│   └── dfsg
└── features
    ├── all
    │   ├── ast
    │   ├── aufs4
    │   ├── qualcomm-emac
    │   ├── rt
    │   └── securelevel
    ├── arm
    ├── arm64
    ├── mips
    └── x86

24 directories

> I think
> you can use the git-debrebase in sid/buster to examine my branch, and
> you can build it with dpkg-buildpackage, but `make-patches' fails.
> 
> I have filed bugs, and fixed them locally and will upload a fixed
> git-debrebase over the weekend.  Apologies for selling you on my new
> tool and then having it crap out...

Heh, no problem.

> 2. Autogenerated files
> 
> gbp pq, which git-debrebase uses, requires debian/control.  There are
> some other things in devscripts etc. which also require
> debian/control.  I decided that debian/control should be in git.

Ok.

> There's a commit message explaning the rationale and some future ideas
> I have for making this less annoying and less baroque, in the commit
> where I edited .gitignore.

>From the commit:

> The templating here is overkill.

Agreed.

> In particular:
> 
>   * Rather than a pile of autogenerated rules in rules.gen,
>     we could have suitable pattern rules, or make macros.
> 
>   * The files like xen-hypervisor-4.11-amd64.postinst could
>     be generated by the rules in a hook.  Then they will
>     want to be ignored again.  But they wouldn't hang off
>     debian/rules debian/control.

Aha, so that 'just building' works, without doing some extra step first.
Yes, and the process of generating could be a dead simple script. (cp a
b, sed s/x/y/?)

>   * The only thing that actually needs some kind of automated
>     assistance, and which needs to be in the source package, is the
>     binary packaage names, and dependencies, in debian/control.
>     We could provide a script to update this in place, maybe, and do
>     away with debian/templates/control.*.in entirely.

+1

Hans