Bug#729203: Rebuild of possible FFmpeg reverse build-dependenciesa
Hi Everyone,
On one system, I have FFmpeg 2.x is installed side by side with Libav ;
The package listing from Synaptic shows;
libavcodec-extra-52
libavcodec-extra-53
libavcodec55-ffmpeg
all installed.
and I found;
ffmpeg-set-alternatives
A helper package to create and remove the alternatives for the ffmpeg.
The Debian alternatives system (man update-alternatives):
It is possible for several programs fulfilling the same or similar functions
to be installed on a single system at the same time. For example,
many systems have several text editors installed at once. This gives
choice to the
users of a system, allowing each to use a different editor, if desired,
but makes it difficult for a program to make a good choice for an editor
to invoke if the user has not specified a particular preference.
Debian's alternatives system aims to solve this problem.
The FFmpeg install is direct from the FFmpeg.org sute.
I'm replacing the network router this week. The week after, I plan to do
some screencasts on the system with FFmpeg 2.2 .
After that I need add two systems to the test bench to practice creating
deb files, and test them.
Once the deb file(s) are successfully tested, they will be uploaded to
the ppa.
All my systems are Kubuntu 13.10 . I use [synaptic] and [apt] removing
muon, pulseaudio & disabling [desktop effects]
>From My Research Desk :)
On 05/04/2014 08:20 AM, Andreas Cadhalpun wrote:
> Hi Niv,
>
> On 04.05.2014 13:03, Niv Sardi wrote:
>> I haven't gotten the time to look more into this, and am now in a 25hrs
>> bus with limited internet access.
>
> I see.
>
>> My rationale is this:
>> - I don't want to ofend the libav maintainers nor want them to go on a
>> +300 api bump.
>
> I don't want to offend them as well, but I don't see, why they should
> have to make any API bump.
>
>> - I don't want anything breaking in debian because users pick our lib on
>> a package that was meant to link to libav and somehow breaks.
>
> To prevent this, FFmpeg is compiled with the --enable-raise-major
> option, so that the FFmpeg SONAME is increased by 100. So no package
> that does not depend on the FFmpeg libraries will use them. (Except
> maybe, if you still use that library in 100 years, which I don't think
> anyone will do.)
>
>> If we keep the names as they are, on next dist-upgrade everybody
>> depending on libavblah will pull it. If we want that, we should go tech
>> ctte and take over Libav, but that wasn't the consensus.
>
> No, a dist-upgrade will not upgrade libavcodec54 to libavcodec155, it
> will only install libavcodec155, if any package depends on it and only
> remove libavcodec54, if no package depends on it anymore.
> And there is no problem at all, if libavcodec54 and libavcodec155 are
> installed in parallel, because the SONAME is different.
>
>> I wanted to see if we had an easy way to alter the soname so this lib is
>> seen as an alternative to the other one and if we can keep packaging in
>> line with policy. In the defect of such possibility, I feel we should
>> rename to libavblah-ffmpegSoname.
>
> I think the easy way you are looking for is --enable-raise-major and
> this is already used.
> And changing the name of the library will not change much, as these
> libraries usually only get installed as dependencies, so the user will
> not see the name. As this package would still include
> libavcodec.so.155, it will have the same (theoretical) problems in 100
> years, when the Libav libavcodec SONAME reaches 155.
>
> So I have the feeling that here is kind of a misunderstanding about
> the effect of changing the package name.
> To be perfectly clear: libavcodec155 from FFmepg and libavcodec54 from
> Libav are co-installable and work fine, if both are installed. You can
> try this, by installing the ffmpeg package and the needed libraries.
> This will not break any existing installed program.
>
> Best regards,
> Andreas
>
Reply to: