[git-buildpackage] Bug#771215: git-buildpackage: please merge support for gbp pq-rpm

[Markus Lehtonen]

On Sun, 2015-01-11 at 10:50 +0100, Tzafrir Cohen wrote:
> On Fri, Jan 09, 2015 at 10:47:27AM +0100, Guido Günther wrote:
> > On Mon, Dec 29, 2014 at 03:41:28PM +0200, Markus Lehtonen wrote:
> > > Hi,
> > > 
> > > On 28/12/14 14:29, "Guido Günther" <agx at sigxcpu.org> wrote:
> > > 
> > > >Hi Markus,
> > > >thanks a lot for the update!
> > > >
> > > >On Tue, Dec 16, 2014 at 10:09:15AM +0200, Markus Lehtonen wrote:
> > > >[..snip..]
> > > >> 
> > > >> You can find a patch with updated unit tests attached. I also updated
> > > >> and rebased my feature/pq-rpm branch in Github.
> > > >
> > > >Can you give a hint what --import-files will be used for? It's already
> > > >a bit sad the we have different branches (packaging vs upstream) for
> > > >the deb and rpm version and --import-files seems to try to
> > > >mitigate this a bit?
> > > 
> > > Basically, yes. For RPM-only packages (i.e. only rpm packaging is
> > > maintained) it doesn't make much sense to have the upstream source code in
> > > the packaging branch, IMO. The source code from the packaging branch
> > > is
> 
> Assuming you have a packaging branch (that is: not a native package).

Yes, of course. Using pq for native packages does not make much sense.


> > Can you point me to a public repo that is RPM-only and one that is
> > not. I'd like to better understand the workflows involved.
> 
> Most of the repositories under http://git.xorcom.com/ are RPM packages.
> The cpbx ones are currently native RPM packages that currently only have
> RPM packaging (may or may not change in the future). Packages under rpm/
> are mainly packaging of external software. Of those, dahdi-linux and
> asterisk are probabbly packages that got more packaging attention.
> 
> That said, those packages represent my ideas of using gbp-rpm, which may
> be differet than Markus's.

Yes, I usually have it bit differently, although your style is
supported. I like to keep the packaging files in a totally separate
branch from the upstream code. That is what you get when using the
--orphan-packaging option with gbp-import-srpm. The reasoning behind the
orphan packaging branch is that when utilizing pq-rpm nothing will
really use the source code in the master branch. Buildpackage-rpm
generates the source tarball from upstream tag (or pristine-tar) and
pq-rpm applies patches on top of the upstream tag. Source code changes
made in master branch make no difference and are totally ignored. Thus,
in my reasoning, the source code in master branch is just a possible
source of confusion and source of git history clutter.

I would like to implement similar support for (debian) gbp-buildpackage
as well but haven't found a nice way, yet. In this case the master
branch would only contain the debian/ directory.

Currently in my git-buildpackage-rpm fork, gbp-buildpackage-rpm has a
command line option (--patch-export) which actually generates patches
from source code changes in the master branch. However, I have started
to dislike this idea and would not like to see that in upstream. I just
have to keep it in my copy for now for historical reasons...

I find it probably a bit unfortunate that --orphan-packaging (in
gbp-import-srpm) is not the default.

I don't have many publicly available examples, but I created one here:
https://github.com/marquiz/devscripts.git (branches example/master and
example/upstream)

As said '--import-files' is a way to ensure that pq-rpm sees the same
configuration in both master and pq branches when they have no common
history. It might be a bit hackish - another way could be to have no
option but always copy/commit .gbp.conf file(s) from the master branch.

Any thoughts, comments? It should still be relatively easy to influence
how the upstream gbp-rpm looks like.

Thanks,
  Markus