Hi,
On 05/18/2012 11:38 AM, Brendan Jones wrote:
On 05/18/2012 03:14 AM, Orcan Ogetbil wrote:
> On Thu, May 17, 2012 at 2:18 PM, Hans de Goede wrote:
>> Hi,
>>
>>
>> On 05/17/2012 06:13 PM, Nicolas Chauvet wrote:
>>>
>>> 2012/5/16 Orcan Ogetbil<oget.fedora(a)gmail.com>:
>>>>
>>>> qtractor is now in Fedora, of course without the libmad support.
>>>> Brendan Jones prepared a libmad-freeworld package with the libmad
>>>> support. This package is analogous to audacity-freeworld as it
>>>> conflicts with the Fedora counterpart since the libmad support is not
>>>> modular.
>>>>
>>>> Do we have a standard procedure here at RPMFusion for X to X-freeworld
>>>> renames? Do we need to file a new review request?
>>>>
>>>> In any case we need to remove the qtractor package from RPMFusion
>>>> repos on F-17 and later.
>>>
>>> From the technical perspective, that rename can be done. (all branches).
>>>
>>> But I would like to avoid using a Conflict here. I don't remember the
>>> audacity case, but for a single binary, it would would be better to
>>> use alternatives with a higher weight for the freeworld version.
>>>
>>>
>>> Now I really wonder why is that much interesting to complicate the
>>> work that much ?
>>> Why bother and what to say when users of the mutilated fedora's
>>> qtractor will complain when cannot import mp3 ?
>>>
>>> The -freeworld was previously reserved for a complementary package of
>>> an existing fedora version.
>>> But in this case I wonder why not to simply override the no
>>> replacement policy ? At least a good reason would need to be provided
>>> for still obeying this policy.
>>
>>
>> Hmm, so you're suggesting to simply have an identical named package
>> in both repos and have the one with the higher EVR win? That is just
>> asking for trouble. I think (if you're right about there being just
>> one binary) that you're alternatives plan is quite good actually.
>>
>> I'm a strong -1 to having packages in rpmfusion which flat out replace
>> Fedora packages. Ideally we also would not have any conflicting packages
>> either, so a +1 to the alternatives approach.
>>
>
> Although technically not a bad solution, as Nicolas says, setting up
> "alternatives" is too much work with too little gain. Why would
> anyone, with having RPMFusion enabled, want to have both of the
> qtractors installed and possibly switch to the Fedora version?
> Practically, "alternatives" does not add much value.
>
> My original plan was to pass over qtractor to some other maintainer
> from RPMFusion this summer, so I am afraid I don't really want to work
> on the "alternatives". This leaves the decision up to Brendan, I
> guess.
>
> Cheers,
> Orcan
The reason why we repackaged this in Fedora is so that we can include it in the upcoming
Fedora Audio spin.
I'm not keen on the scenario where both packages are present and agree with Orcan
that the alternatives approach does not really add any benefit. What is is so bad with a
qtractor-freeworld replacing the Fedora version? Presumably anyone who installs this
package knows what they are doing and why.
The problem is that to replace the package, it will need a higher EVR, and
then when Fedora bumps version the Fedora version may become newer and
then yum will upgrade to the Fedora version removing the mp3 support.
So the best solution is either using alternatives or a conflict. I'm sure a
conflict + provides (in case anything depends on qtractor) will work fine and
that is a very simple solution. Having 2 packages with the same name in 2
different repo is just asking for trouble...
Regards,
Hans