Hi, On Wed, Mar 04, 2015 at 12:30:43PM +0200, Markus Lehtonen wrote: > 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.
I hat a look at this too already. Just ping before you put time into it so we don't waste efforts. > > > 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. Awesome. Thanks for your feedback! -- Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
