Hello, Bernd. Thank you for your reply, answers inline:
2011/6/1 Bernd Zeimetz <be...@bzed.de>: >> 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 debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=dy+pqanwcqicpjbj5rwuqubt...@mail.gmail.com
