Moving xine-lib and dependent apps to RPM Fusion Free for F17?

[Xavier Bachelot]

On 07/10/2013 01:42 PM, Michael J Gruber wrote:
> Do you top-post on rpmfusion-developers? I'm sorry if I messed that up,
> I'm not on that list and don't know the policy.
>
As on most lists, no, we don't top post, but no worries ;-)

> We were talking about restructuring the xine packages, and xine-ui was
> supposed to be subsumed by another package if I remember correctly.
>
Ok, I see what you had in mind now.
Currently, xine-lib is split into the main package in Fedora, and a 
companion package in RPM Fusion (xine-lib-extras-freeworld) that ships 
all the bits of xine-lib that cannot be in Fedora for some reason.
xine-ui and the other xine-lib dependant packages don't suffer from this 
kind of split, so they'll stay as they are, just at a different location.

> Do we move first than repackage?
>
I guess the plan could be to have all the packages created in RPM 
Fusion, then all the packages retired from Fedora. We'll need to first 
build xine-lib, then all the other packages. I don't have experience on 
this particular matter, so I welcome any advice. Especially, I don't 
know if the moved packages will need to be re-reviewed or not. There is 
a review ticket open for xine-lib in RPM Fusion bugzilla, but this is a 
bit different, as this is about merging xine-lib and 
xine-lib-extras-freeworld packages.

Please note the target is Fedora 20, so we'll have a bit of time to land 
all of this in devel, I'd say the target could be before branching 
Rawhide for F20. Indeed, the packages that are currently in Fedora 19 
and earlier and EPEL are not affected. Only the devel and f20 branches 
will be touched.

> In that case we would need an rpmfusion maintainer for xine-ui, or I
> would need to become one. If someone wants to jump in - by all means go
> for it. Otherwise I hope that rpmfusion maintainership doesn't differ
> too much from fedora maintainership in terms of tools etc. I won't be
> able to before mid August, though.

RPM Fusion strictly follows the Fedora packaging guidelines, but is less 
strict on the allowed software and licenses. However, the tools are a 
bit different than what we have now in Fedora (git vs cvs, koji vs 
plague, bodhi vs manual scripts). I think moving closer to the Fedora 
build infrastructure is in the works, but I don't know about the current 
status.

About maintainership of the packages, the easiest would probably be to 
keep the current maintainers. That's true even for xine-lib, but as I'm 
looking at updating it to a more recent release and Kevin wants to step 
down from maintaining it, I'm de facto volunteering myself ;-) About 
xine-ui, that's one of the frontends I'm using so I could be maintainer 
or co-maintainer if you wish, but again, I'm not trying to grab more 
packages, I have already my share ;-)
>
> Michael
>
Regards,
Xavier

> Xavier Bachelot venit, vidit, dixit 10.07.2013 12:34:
>> On 07/10/2013 11:57 AM, Michael J Gruber wrote:
>>> Xavier Bachelot venit, vidit, dixit 10.07.2013 10:58:
>>>> Hi,
>>>>
>>>> On 01/05/2012 08:56 PM, Kevin Kofler wrote:
>>>>> The following packages currently depend on xine-lib:
>>>>> * gxine
>>>>> * (k9copy – already in RPM Fusion, not affected)
>>>>> * kaffeine (my package, the reason why I maintain xine-lib in the first place)
>>>>> * oxine
>>>>> * xine-plugin
>>>>> * xine-ui
>>>>> These packages would have to move to RPM Fusion along with xine-lib.
>>>>
>>>> Fwiw, I've rebuilt all the above packages (but k9copy, not tested yet)
>>>> against the xine-lib 1.2.3 rpm I prepared and all the builds succeeded.
>>>> No runtime tests yet.
>>>>
>>>> Would all the impacted maintainers be ok to move their package to RPM
>>>> Fusion, alongside with xine-lib 1.2 ?
>>>
>>> Yes, more than happy.
>> great.
>>
>>> I assume that packages such as xine-ui would be
>>> subsumed in other packages then?
>> I'm not sure to understand what you mean here, but each package would be
>> retired from Fedora and a corresponding package be created in RPM
>> Fusion. The RPM Fusion maintainer can be the same person as the former
>> Fedora maintainer, as a sponsored Fedora packager is entitled to be an
>> RPM Fusion packager automatically. Indeed, if the Fedora packager
>> doesn't want to keep maintaining his package in RPM Fusion, another
>> maintainer will have to be found or else the package would have to
>> unfortunately be retired, if no one steps up.
>>
>>> I'd pass over maintainership to the
>>> corresponding superpackage maintainer then.
>>>
>>> Michael
>>>
>> Regards,
>> Xavier
>>