Got answer from debian-python mailing list which didn't appear to get into debian-mentors. Forwarding conversation here:
2011/6/1 Andriy Senkovych <[email protected]>: > Hello, Bernd. > > Thank you for your reply, answers inline: > > 2011/6/1 Bernd Zeimetz <[email protected]>: >>> This approach is tested and may be observed on my test site [6]. It >>> allows me to test package building during the same CI process as >>> development because package will be rebuilt on both upstream VCS >>> update and debian package source VCS update. However I'm not the first >>> one willing to perform this so maybe there is a better way to organize >>> this. >> >> I'd do it as you've described it above - maybe run it trough cowbuilkder >> with git-buildpackage. > > Right, I thought about it as well. > >>> Also I'm looking for a scalable in sense of Linux distributions >>> (or even Windows in future) and I'm not sure how to scale current >>> approach. It appears I would need a separate repository for every >>> distro which is not very great I believe. >> >> One branch with the proper debian/gbp.conf should be enough, I think. >> Just make sure you build with a chroot according to the diustro you want >> to build for using cowbuilder/pbuilder/sbuil/whatyoulike. > > And here comes the problem: the upstream has one repository, it > releases two tarballs(master and slave), which are imported then in > Debian git repositories and then built. Note that contents of the > tarballs and the subdirs in upstream repo differ. So I cannot actually > include the debian work as a separate branch in upstream repo as I > would like to do. So currently I see the following ways and both are > not looking good: > > 1) add a Debian branch to upstream. It doesn't make much sense If I'm > going to prepare Debian releases because I'll need to do same things > twice. But the code base will be in one place and that's good. > Hopefully I could manage other distros have their separate branches > and find tools useful for this kind of situation. > 2) support separate Debian package repositories (in this case 2: > master and slave). This means heterogeneous configuration if some > distro will use branch in upstream repo. And this means that I could > need double number of repositories to support a single number of > distros. So its even worse. > > Maybe I missed something and git-buildpackage could manage first case > better than I think? Or is there could be some way to improve > git-buildpackage with some generous features to make this situation > less painful? -- WBR, Andriy Senkovych -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
