Hi,` On Fri, Jan 06, 2012 at 08:02:17PM +0100, Daniel Dehennin wrote: > Guido Günther <a...@sigxcpu.org> writes: > > I don't really know if BTS is the good place to speak about this, but > lets go. We can move over to git-buildpack...@packages.debian.org but I think this bug is the correct place to discuss the implementation.
[..snip..] > I thought about forgetting the branch name in that regards and use one > debian/gbp.conf per packaging branch. > > So, if I want to make some tests, I can create new temporary branches > and avoid setting many command line options. That's o.k. as long as you don't merge between these branches frequently in which case you either need a merge driver to not merge gbp.conf between them. > >> I think having on base-DIST-ARCH per distribution I maintain is more > >> useful than per branch name. > > > > What do we do in the UNRELEASED case? Fall back to the last changelog > > line that sets a distribution? > > Seems reasonable to me. > > I finally test sbuild in replacement of cowbuilder and figure out that > there is several concepts here: > > - distributions used for "debian/changelog" > > - distributions used to build the package > > I can have several "debian/changelog" distributions sharing the same > "build" distribution. > > I mean of making a snapshot of the same schroot. > > In that regards, schroot seems much better than cowdancer, due to its > "aliases" option. I can share the same logical volume for several > "build" distributions. > > I'll look at managing sbuild with git-buildpackage. > > I wonder if I extend git-pbuilder or making something different. I haven't used sbuild much but given that it's a completely different implementation a different script (using the same env vars) would be best. [..snip..] > I spoke about using "debian/changelog" in git-pbuilder because it's a > shell script and I assumed that the "debian/changelog" was the canonical > place which store that information /outside/ git-buildpackage. > > I don't think it's useful to use "debian/changelog" /in/ > git-buildpackage[1], using explicit options[2] make it clear of what > happens and when. I think it's much better suited in git-buildpackage itself since it's easier to drive the change from there and we don't have different places parsing the changelog then. You can also easier set options via gbp.conf from there. > Maybe it's better to be forced to edit a file or use command line > options for that than using some will-break-something-one-day magic. That's basically what git-buildpackage does in this regard, it drives the env vars for git-pbuilder. [..snip..] > [1] I make a difference between the python code and shell scripts, the > later could be user specific. > > [2] --dist does not exist yet for git-dch by the way ;-) Yes, that's still missing but git-dch needs some cleanups first since the dch invocation is messy at best. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
