Hi, On Fri, 2015-02-20 at 11:25 +0100, Guido Günther wrote: > On Fri, Feb 20, 2015 at 09:36:52AM +0200, Markus Lehtonen wrote: > > >There were two things I didn't like about the svn workflow for Debian > > >packages. debian/ and upstream source not in one tree (so I can not > > >build with a patched package easily to try fixes) and having to use an > > >export dir (slowing down the build and not giving me a single source > > >tree to grep through). > > > > Good to hear arguments why this is not supported. My understanding is that > > having source code changes is not possible in the 3.0 (quilt) format. Thus, > > trying out fixes requires usage of gbp-pq, anyway. Please correct me, if > > I'm wrong. > > It is supported with some configuration, basically using > > single-debian-patch > > in debian/source/options .
I didn't know about this, thanks for pointing this out! In this case, it might make sense to implement something similar in buildpackage-rpm. A new command line option would be needed, --git-create-single-patch or something. I put this in my backlog so let's see... > > >It seems that having the packaging separate > > >brings back these two things some I'm opposed > > > > Basically, yes :( > > Would you oppose making this an optionally supported mode, if the > > maintainer > > so chooses? It shouldn't require too many changes, e.g. probably making > > pq-import to apply patches on top of the upstream version instead of the > > tip of the packaging branch and making gbp-buildpackage to export > > upstream-tree + packaging-branch instead of just packaging-branch. > > I'm not sure we want to support that many different workflows but if > there are users for this: why not! > > I still do think simply writing the debian/ tree is less effort and > easier since you just have to look at that single branch then. OK, I have this in my backlog, too. I'll let you know when/if I have something worth of sharing. > > Also, I have some ideas how to enable building without having to use a > > separateexport directory in this mode. I think I'd need to try it out and > > post a conceptual patch for comments. > > Great! Since building wick pbuilder/sbuild/mock creates another copy > we should really try to avoid that one. Also this is in my todo-list. > > >but maybe there are > > >good arguments in favour of just omitting the merge and putting > > >debian/ into the upstream tree? > > >If we create a fake merge commit it's even easy to see where the > > >upstream source came from. > > > > Were you thinking about 3.0(quilt) format here? IMO, this sounds better > > than > > the original idea. > > > > I've had similar ideas, but for the pq-branch, i.e. making it possible to > > do builds directly in the pq-branch. But again, I think I need to think > > about it a bit more and probably send a proof-of-concept patch for > > comments. > > That does already work. The extra steps are that you either have to > sync debian/patches via "gbp pq --commit export" or use > single-debian-patch as above. The major drawback at the moment is that > you usually don't push the pq branch since it's being rebased but we > could fix that too by creating fake merges into a long lifed branch. I was thinking a way without needing to do the extra step of "gbp pq --commit export". But it seems that the single-debian-patch (and a possible counterpart in buildpackage-rpm) should do. Thanks, Markus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
