EPEL libbluray soname bump in

[Xavier Bachelot]

On 01/04/2014 07:14 PM, Xavier Bachelot wrote:
> Hi,
>
> On 01/03/2014 10:05 PM, Orion Poplawski wrote:
>> >I'd like to call attention to:
>> >
>> >Setting up Upgrade Process
>> >Resolving Dependencies
>> >--> Running transaction check
>> >---> Package libbluray.x86_64 0:0.2-0.6.20110710git51d7d60a96d06.el6 will be
>> >updated
>> >--> Processing Dependency: libbluray.so.0()(64bit) for package:
>> >mencoder-1.0-0.140.20120205svn.el6.1.x86_64
>> >---> Package libbluray.x86_64 0:0.5.0-2.el6 will be an update
>> >--> Finished Dependency Resolution
>> >Error: Package: mencoder-1.0-0.140.20120205svn.el6.1.x86_64
>> >(@rpmfusion-free-el6-updates-testing-x86_64/6.1)
>> >            Requires: libbluray.so.0()(64bit)
>> >            Removing: libbluray-0.2-0.6.20110710git51d7d60a96d06.el6.x86_64
>> >(@epel-6-x86_64/6.1)
>> >                libbluray.so.0()(64bit)
>> >            Updated By: libbluray-0.5.0-2.el6.x86_64 (epel-testing)
>> >                Not found
>> >
>> >https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12460/libbluray-0.5.0-2.el6
>> >
>> >
> The update has been unpushed.
>
> The karma messages is not the right place to discuss, so let's do it here.
>
> The only dependency for this library is mplayer from RPM Fusion. mplayer
> maintainer is ok to rebuild, but RPM Fusion admin is not ok to grant a
> buildroot override. I know the update is a soname bump, it was my
> mistake to build an early libbluray version in EPEL, and I won't do it
> again, but I don't see how plainly refusing the buildroot override
> without explanation from any side is helping, especially when the
> maintainer of the one and only depending package is ok to rebuild. I'm
> just trying to have a maintainable and useful library in EPEL, and I'd
> rather drop it than keep it this way, because it is missing a lot of
> features and will break sooner or later. People will just have to wait
> for RHEL 7 and clones to get it again.
>
> In short, I don't want to maintain this old libbluray in EPEL 6 and
> there's nothing I can do to avoid the temporary breakage unless RPM
> Fusion admin changes his mind, so either one find a way to have it
> updated then mplayer rebuilt against it, either I'll probably drop it
> and other dependant packages (which will require an mplayer rebuild anyway).

What I expected to happen is now happening, libbluray in EPEL 6 is too 
old to be useful and people wanting to use it are asking for an update.

Nicolas, can you please explain why you are not willing to grant a 
buildroot override ? As already explained, I need it to be able to push 
an update and ensure the dependency breakage will be kept to a minimum 
rather than a full 15 days until the package goes from EPEL testing to 
EPEL stable (which might very well never happen if the update is shot 
down because it breaks dependency, like it already happened once), plus 
the time needed to rebuild and push mplayer in RPM Fusion.
Chicken and egg problem, if you ask me, and the override is the only way 
to ease it, especially when the involved packages are spanning over 
multiple repositories.

Also, I'd really like to document how to request a buildroot override in 
the wiki, so any explanation is welcome. I've asked several time already 
on the IRC channel and also on the mailing list.

Regards,
Xavier