[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Incomplete ben file for libav9 transition?



On Thu, May 30, 2013 at 8:54 AM, José Manuel Santamaría Lema
<panfaust@gmail.com> wrote:
> Hello Reinhard,
>
> Reinhard Tartler <siretart@gmail.com>
>> On Wed, May 29, 2013 at 12:18 AM, José Manuel Santamaría Lema
>>
>> <panfaust@gmail.com> wrote:
>> > Hello,
>> >
>> > unless I'm missing something, I think in the ben file you may have
>> > missed:
>> >
>> > - In Bad: packages depending on libavcodec-extra-53, libavcodec-extra-53
>> > and libavutil-extra-51
>> >
>> > - In Good: packages depending on libavcodec-extra-54, libavcodec-extra-54
>> > and libavutil-extra-52
>>
>> Packages are not supposed to depend on libavcodec-extra-53 or
>> libavcodec-extra-54, unless really really necessary. Can you show
>> examples that explicitly depend on the -extra- variants, and only
>> them?
>>
>> I only know of devede, and would like to know if they are more offenders.
>
> With this ben query;
> ben query ".depends ~/libavcodec-extra-53/ & ! .depends ~/libavcodec53/" -s
> Package,Version,Source,Architecture,Depends *
>
> I found out that dvd-slideshow is also affected. I tried similar queries for
> avformat and avutil but I found nothing.

I have uplodaded a new libav package to experimental that contains the
libavcodec-extra meta-package, so packages can depend on the extra
functionality in a robust manner. Please note that only GPLv3
application can do so, GPLv2 (probably) must not do so.

>
> Also I would like to mention some things more, which you may find interesting:
> for some reason when you build a package with sbuild and the aptitude resolver
> you don't get a depend on libavcodec53 | libavcodec-extra-53, but a depend on
> the extra package and only the extra package. See for instance amarok in
> experimental for amd64. This happens when the sbuild aptitude resolver doesn't
> install libavcodec53.

I've seen that as well, and I think this may be problematic. I've
tried to express this issue in the past, but was unable to explain why
this is a problem. Since then, I'm waiting for someone else to see the
license-wise problem that arise here.

>
> It also happened to me randomly when building other KDE 4.10 packages, such as
> src:nepomuk-core and src:ffmpegthumbs.
>
> I realized about this problem because I'm maintaining an unofficial repository
> with KDE packages for debian similar to the old qt-kde.debian.net. A couple of
> users told me that their upgrades wanted to remove amarok and other stuff. This
> problem happened only with apt-get, but not with aptitude, but since official
> debian KDE 4.10 packages from experimental are difficult to install/upgrade with
> apt-get, and the current debian qt/kde team stopped using qt-kde.debian.net
> (which would made the upgrades easier with apt-get and easier in general),
> nobody in debian realized about this problem.

can you explain why this is a problem?

> To workaround the problem I added libavcodec53 to the build depends of my
> customized packages amarok, nepomuk-core and ffmpegthumbs, thus I'm getting the
> correct depends, even while I'm building my packages with sbuild and the
> aptitude resolver.

I do not think that this is a good solution.

Cheers,
Reinhard


-- 
regards,
    Reinhard


Reply to: