Re: Upstream looks for a proper way to build the packages by itself
Got answer from debian-python mailing list which didn't appear to get
into debian-mentors. Forwarding conversation here:
2011/6/1 Andriy Senkovych <jolly_roger@itblog.org.ua>:
> 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: