[pkg-wine-party] Wine packaging team, Re: Bug#758291: Bug#758291: Complete solution for update-alternatives

jre jre.winesim at gmail.com
Mon Jul 20 16:08:45 UTC 2015


Hi again (continuing on the list only)

On 07/20/2015 05:32 PM, jre wrote:
> On 07/19/2015 11:45 PM, Michael Gilbert wrote:
>> On Sun, Jul 19, 2015 at 1:03 PM, jre wrote:
>>> Please let me know if this sounds good to you and whether I should start
>>> working on this again.
>>
>> I was planning to wait for 1.8 to come out to do the
>> stable/development packaging unificiation, and then after that to work
>> on the alternatives setup.
> 
> Therefore I suggest to go ahead with the alternatives setup now
> *without* unifying the packaging yet, while already implementing it in a
> way that doesn't have to be changed later on.

I'd be happy to generally help more. Of course I'd like to push my pet
projects. But there's also the regular bug stuff, where I could commit
fixes directly if I were part of the Alioth team. Or I could sort & wrap
the files in debian/ which were littered a bit over the years. And I
might update the instructions on https://pkg-wine.alioth.debian.org/, or
join Stephen in the gecko copyright madness. I could also apply as
Debian Maintainer and upload the packages directly. (I do local
packaging work and look at Debian including its social ecosystem from a
packager's perspective since about 10 years.)
Of course I only want to do stuff as part of and in agreement with the
team (especially Mike). I don't want to burden you or interfere with
your work in any way. So if this would break your workflow please just
go ahead with your wonderful work. In the end joining only makes sense,
if there is a net gain for the Wine project.

About your plans for the unification - that sounds like what I also
think works best: Start a new branch from master when Wine 1.8 is
released, and from then on only commit debian changes to it. Then use
git-buildpackage with a given upstream branch and the new branch as
debian branch. The Debian packaging itself might be adapted somewhere
along the lines I proposed last year (gbp simplifies the patch- and
changelog management, but I didn't think of it back then).

(Finally this could also be extended to support wine-staging, be it with
or without actual packages in Debian.)

Greets
jre



More information about the pkg-wine-party mailing list