Re: Upstream looks for a proper way to build the packages by itself
Hello, Bernd.
Thank you for your reply, answers inline:
2011/6/1 Bernd Zeimetz <bernd@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
Reply to: