libxxx-dev should be installable with libxxx-unstripped

[Ludovico Cavedon]

Binary package hint: ffmpeg

libxxx-unstripped should also
Provides: libxxx

so it would possible to have libxxx-dev and libxxx-unstripped installed at the same time.
Thanks

[Reinhard Tartler (siretart)]

this would make it possible to build packages against libavcodec-unstripped-52 by accident.

What's the use case for this? do you want to build packages or your personal software? If the latter, I'd suggest that you build against a private copy of ffmpeg anyways. If the first, well, no.

[Ludovico Cavedon (cavedon)]

This is my use case: I am maintainig the debian package for qutecom (ex wengophone). It depends on ffmpeg (so I need libavcodec-dev). At runtime it will enable video support if h26[13] video encoders are avavilable. So, in order to test this part, I need to remove -dev and install -unstripped libraries.

However I see your point about building against the wrong package...

[Ludovico Cavedon (cavedon)]

One question: official ubuntu packages in universe are built without packages from multiverse being available, correct? So this risk should not be there...

[bojo42 (bojo42)]

a good solution to that problem would be a unstripped-dev package in multiverse, AFAIK you are currently not able to build against the unstripped packages.

[Ludovico Cavedon (cavedon)]

If you had unstripped-dev, now you would like them to Provide: the stripped -dev version, otherwise dpkg-buildpackage would refuse to build it. So the problem would be the same.

But, as I said, if packages in universe are build without multiverse (which sounds reasonable), I do not see the problem of having libxxx-unstripped packages in multiverse Provide: libxxx

[bojo42 (bojo42)]

@Ludovico: can you explain that a bit more in detail, as from my point of understanding i don't get why the unstripped-dev should provide the stripped-dev. I would say the unstripped should conflicts the stripped one, of course that would mean you can't build packages that depend on one or the other at once.

Generally my reason for wanting a unstripped-dev is that i could let the PPA system build packages that need the stripped stuff of ffmpeg, without hosting a own ffmpeg package in my PPA. Beside i would think this would also make things easier when preparing packages for multiverse, as you just have to add a unstripped-dev as build depends and you got all the "nasty" stuff.

I stumbled of this when i tried to get all of Ekiga's non free plugins into my PPA for easy sharing to friends of mine who need those. Maybe i'm missing something, so please correct me or explain :), but i don't get why there is no "nasty" dev package of ffmpeg, since i thought there was one in Medibuntu.

best regards
bojo42

[Ludovico Cavedon (cavedon)]

Applications built against the stripped version should be able to run against the unstripped version without recompilation (and in fact qutecom/wengophone is able to); the application should just have fewer or more codecs available (are there other differences btw?).

I want to be able to build the official package using the stripped-dev libs and run it against the unstripped runtime.
Yes I could work in a chroot, but sometimes it is annoying....

[Reinhard Tartler (siretart)]

Ludovico Cavedon <email address hidden> writes:

> Applications built against the stripped version should be able to run
> against the unstripped version without recompilation (and in fact
> qutecom/wengophone is able to); the application should just have fewer
> or more codecs available (are there other differences btw?).

check debian/strip.sh in the ffmpeg-debian package

> I want to be able to build the official package using the stripped-dev
> libs and run it against the unstripped runtime.

well, that's how all packages in debian and ubuntu are currently
built. I fail to see the problem here?

> Yes I could work in a chroot, but sometimes it is annoying....

I can only recommend building packages in clean chroots...

The only valid use case for this request I could imagine would be if
there was some packages that really requires the
libavcodec-unstripped-52 installed and does not work with libavcodec52
at all. I haven't seen such a package so far, though...

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

[Ludovico Cavedon (cavedon)]

Reinhard Tartler wrote:
> Ludovico Cavedon <email address hidden> writes:
>> Applications built against the stripped version should be able to run
>> against the unstripped version without recompilation (and in fact
>> qutecom/wengophone is able to); the application should just have fewer
>> or more codecs available (are there other differences btw?).
>
> check debian/strip.sh in the ffmpeg-debian package

Looks like there are no other differences

>> I want to be able to build the official package using the stripped-dev
>> libs and run it against the unstripped runtime.
>
> well, that's how all packages in debian and ubuntu are currently
> built. I fail to see the problem here?

That was in answer to bojo42, who was proposing unstripped-dev packages.

>> Yes I could work in a chroot, but sometimes it is annoying....
>
> I can only recommend building packages in clean chroots...

I agree, but sometimes for development and testing it is convenient to
work outside.

> The only valid use case for this request I could imagine would be if
> there was some packages that really requires the
> libavcodec-unstripped-52 installed and does not work with libavcodec52
> at all. I haven't seen such a package so far, though...

I am not referring to this case.

My use case is: qutecom/wengophone video support is disabled at runtime
if ffmpeg is stripped. Currently I am not able to compile and run it and
test the video, without keeping on switching between -dev packages and
unstripped packages,

[Reinhard Tartler (siretart)]

Ludovico Cavedon <email address hidden> writes:

> My use case is: qutecom/wengophone video support is disabled at runtime
> if ffmpeg is stripped. Currently I am not able to compile and run it and
> test the video, without keeping on switching between -dev packages and
> unstripped packages,

hm, for that use case, you can use the '--force-depends' of dpkg to
install the -dev packages anyway, I'd say.

if you really insist that we should add the dependency, let's please
discuss this in a debian bugreport, ok?

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

[Ludovico Cavedon (cavedon)]

Reinhard Tartler wrote:
> hm, for that use case, you can use the '--force-depends' of dpkg to
> install the -dev packages anyway, I'd say.
>
> if you really insist that we should add the dependency, let's please
> discuss this in a debian bugreport, ok?

ok, thank you for the hint

[Andrej Krutak (andree182)]

After reading this thread I still don't really see the problem - I have the -dev packages and the ideal case would (imo) be, that I can either choose stripped or unstripped versions of "binaries". I don't really see, how:

"this would make it possible to build packages against libavcodec-unstripped-52 by accident."

would be a problem. If I compile whole ffmpeg by myself, I may too compile against *unstripped* by accident...

I tried the --force-depends, and fortunately got the -dev packages + *unstripped*, but I think it's a bit too much of a hassle. Without this (maybe standard, but still) trick, the *unstripped* packages are basically not installable (because of dependencies etc.) and thus unusable... And of course, aptitude's still screaming about the unsatisfied depedencies (-dev=>*stripped*)...

The dev packages are mostly used by developers, who in turn (mostly) know, why they install *unstripped*... I would vote for "fixing" the provides/replaces/conflicts for these packages.

[Vladimir Mityukov (mityukov)]

libav*-dev packages conflict with libav*-unstripped-52. There are two solutions, imo:
1. fix dependencies between "libav*-dev" and "libav*-unstripped-52" somehow;
2. add new packages: "libav*-unstripped-52-dev".

Note: "libav*-dev" required when building something from sources. For example: http://kradio.sourceforge.net/

[arturo (arturo-openframeworks)]

just updated to jaunty and it seems to install the unstripped packages by default, so the -dev packages conflict with that and to install them you need to remove software like blender, vlc, gstreamer-ffmpeg... then you can install it again of course, but it should be better that in the update the normal libxxx packages get installed or that the -dev pacakges could be installed using the unstripped ones.

[Reinhard Tartler (siretart)]

arturo <email address hidden> writes:

> just updated to jaunty and it seems to install the unstripped packages
> by default,

what makes you think so?

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

[arturo (arturo-openframeworks)]

because previously i had the libxxx versions and when updated to jaunty from intrepid it replaced that with the unstripped ones and removed the -dev packages

[bojo42 (bojo42)]

i can confirm that this still makes troubles on jaunty, as the rather common ubuntu-restricted-extra package recommends libavcodec-unstripped-52. due to apt's default behaviour to install recommendations nearly everybody with ubuntu-restricted-extra can't use the dev packages in a clean way. of course this not an (meta)package from the default installation, but as i said it is really common to install it, so i am at least for fixing the dependencies.

[bojo42 (bojo42)]

regarding all those duplicates and the current situation i think a status of confirmed is adequate

[Yonas (yonas-y)]

Please fix this bug! I had this problem when compiling VLC in jaunty:

https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/356076

[frank (dallco)]

compiling openmovieeditor from source requires gmerlin-avdecoder this depends on libavutil-dev that is not installed without libavutil49.....
Yonas +1
 Fix this bug please.

[Evan R. Murphy (evanrmurphy)]

I think this bug is keeping Ekiga from recognizing the h263 video codec I need.

> hm, for that use case, you can use the '--force-depends' of dpkg to
> install the -dev packages anyway, I'd say.

I'd like to test whether forcing libavcodec-dev against libavcodec-unstripped-52 unblocks h263 for Ekiga, and I was trying to use the above command but couldn't make it work. Could someone show me the error in "sudo dpkg --force-depends -i libavcodec-dev"?

For the record, I also tried installing libavcodec52 and libavcodec-dev (instead of the unstripped version, since it excludes -dev), along with their dependencies, but this didn't solve my problem.

[volkris (volkris)]

@Evan: --force-depends won't unlock the Ekiga h263 codec because it's not there to be unlocked in the first place :)

The codecs for Ekiga have to be built through opal (bug 316971) and a few would require unstripped-dev at build time... but there is no unstripped-dev, so those codecs are never packaged at all. bojo42 is here looking to resolve that by requesting an unstripped-dev (I think).

Anyway, it looks like this bug is unfortunately muddled by different packages being affected by the stripped/unstripped issue in different ways. Sucks.

[Reinhard Tartler (siretart)]

Evan Murphy <email address hidden> writes:

> I think this bug is keeping Ekiga from recognizing the h263 video codec
> I need.

Why would you need the -dev package for having the h263 codec in ekiga?

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

[volkris (volkris)]

Ekiga doesn't use libavcodec directly, so just having libavcodec-unstripped around isn't enough.

Instead, Ekiga's codecs are distributed as plugins built by libopal, which has to be built against the unstripped-dev package.

bojo42 has packaged all of the codecs that he could (h264 and ilbc, see his ekiga ppa) but he couldn't do h263 without unstripped-dev

[Ludovico Cavedon (cavedon)]

I still think that the simplest solution is what is state in the bug title:

libxxx-unstripped should also Provide libxxx

I still do not understand what is the problem with that. And is also semantically correct: libxxx-unstripped *provide* eveything that libxxx does, plus something more.

[volkris (volkris)]

Did anyone file the debian bug report Reinhard suggested?

If that's the "proper" way to handle this, then let's get to it.

[Reinhard Tartler (siretart)]

Chris Carlin <email address hidden> writes:

> Ekiga doesn't use libavcodec directly, so just having libavcodec-
> unstripped around isn't enough.
>

In ubuntu, we do not want ANY applications to be built against the
*unstripped* variants of libavcodec as a saftey guard. If users want to
do that at home, fine, but we actually cannot do that in ubuntu because
that introduces just even more confusion as we already have in this bug.

First: Please have a look and understand what actually is stripped. The
stripping process just removes some encoder av_register_codec
calls. I cannot see how this modification can possibly affect
applications building against libavcodec. If you have such an example,
please show me.

This means: Building against the regular libavcodec-dev package and then
replacing libavcodec-unstripped-52 should produce exactly the same
result as linking against an "unstripped" libavcodec-dev package. The
latter btw does not exist since it would be byte-identical to the
stripped version.

> Instead, Ekiga's codecs are distributed as plugins built by libopal,
> which has to be built against the unstripped-dev package.

With the rationale above, I can assure you that the 2nd statement "has
to be built against the unstripped-dev package" is plain wrong.

I'm currently considering adding an alternate dependency on the -dev
packages because of popular request. "Provides" is the wrong solution
since it breaks versioned dependencies. But I'm still unsure if people
here are just misguided because of rumor or misinformation. I still have
not seen a single case where this chance is absolutely necessary beside
from the convenience of not having to install the unstripped package
over.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

[Vladimir Mityukov (mityukov)]

2Reinhard Tartler:

> In ubuntu, we do not want ANY applications to be built against the
> *unstripped* variants of libavcodec as a saftey guard. If users want to
> do that at home, fine, but we actually cannot do that in ubuntu because
> that introduces just even more confusion as we already have in this bug.

Understood.

However, I'm not sure, that I got this sentence correctly:
> This means: Building against the regular libavcodec-dev package and then
> replacing libavcodec-unstripped-52...
...

English is not my native language... Do you mean "Build against regular libavcodec-dev and then replace this libavcodec-dev by libavcodec-unstripped-52"?. Or, should I replace libavcodec-unstripped-52 by something?

Side note: I'm pretty sure, kradio does not require "unstripped" libav*-dev packages.. However, I can't install "regular" ones as well, if I have "kubuntu-restricted-extras" installed (and I have it, since it's useful for me), because they conflict.

That's the problem..

[Reinhard Tartler (siretart)]

Vladimir Mityukov <email address hidden> writes:

> English is not my native language... Do you mean "Build against regular
> libavcodec-dev and then replace this libavcodec-dev by libavcodec-
> unstripped-52"?. Or, should I replace libavcodec-unstripped-52 by
> something?

I mean installing libavcodec-unstripped-52. That in effect will replace
the packages libavcodec-dev and libavcodec52. NB: The latter is a
dependency of libavcodec-dev.

> Side note: I'm pretty sure, kradio does not require "unstripped"
> libav*-dev packages.. However, I can't install "regular" ones as well,
> if I have "kubuntu-restricted-extras" installed (and I have it, since
> it's useful for me), because they conflict.

So the problem is that you cannot install kubuntu-restricted-extras with
libavcodec-dev at the same time? Is that a real problem? why?

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

[Yonas (yonas-y)]

I've made a Debian bug report for this problem:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526007&archived=False&mbox=no

[Yonas (yonas-y)]

Off topic:

I had to use a command-line program/email to file that bug in debian......it's 2009!!!!!!! If my kids ever ask me, "Hey pops, what were you doing in 2009??", I will hang my head in shame and tell them, "I can tell you, but it's so embarrassing, I'd have to kill you."

[bojo42 (bojo42)]

@Reinhard: many thanks for explain the issue a bit more in detail, cause now i finally got it. better later than never ;) and BTW i think it was rather not enough information than misinformation that lead to my wrong assumptions ;)

@all: and yes with dpkg -i --force-depends i was also able to build the opal/ekiga stuff using the unstripped packages. so we don't really need "unstripped dev" packages for using the unstripped libs in packaging. but anyway we need a solution for the "dependency hell" right now, as you can only build packages by "corrupting" the package system and this is not good for PPAs and everything else beside chroot.

as for the rivalling of *ubuntu-restricted-extras and the dev packages, i would argue that even people who do some packaging or compiling should be able to do this on the same machine they use for their unfree multimedia experience. (meaning without a lot of package installation :)

[Vladimir Mityukov (mityukov)]

> > Side note: I'm pretty sure, kradio does not require "unstripped"
> > libav*-dev packages.. However, I can't install "regular" ones as well,
> > if I have "kubuntu-restricted-extras" installed (and I have it, since
> > it's useful for me), because they conflict.
>
> So the problem is that you cannot install kubuntu-restricted-extras with
> libavcodec-dev at the same time? Is that a real problem? why?

Not exactly. The problem is that I can't build some useful program (e.g. KRadio), which requires "libav*-dev" packages, if I have kubuntu-restricted-extras installed (already installed, long time ago). When I build the KRadio program from sources, it tells me that I won't have "internet streaming"(the feature, which I actually need the most), because I don't have some libs/headers from ffmpeg. And when I try to install these libs/headers, using aptitude or apt-get -- I get "Conflicts with kubuntu-restricted-extras" message.

There can be some other programs, which are not in the repos (or the repos have outdated versions), but still requiring the same dev packages.

> .. unfree multimedia experience

Here, in Russia, these patents don't have any legal effect. So, it's completely free for some countries ;-)

[bojo42 (bojo42)]

added "ffmpeg-debian" as the bug is rather fixed there than in the "ffmpeg" source package. as this issue is now fixed in debian (thanx to all involved) it's now up to fix it in ubuntu too. for karmic this should be done with a debian import, but for jaunty we will need a SRU (https://wiki.ubuntu.com/StableReleaseUpdates). as it's a really safe small change in debian/control i don't think this should be a big deal, but i'm not sure if this issue meets the mentioned requirments for a SRU. otherwise we could do a backport, but this won't fix it really good, as most people haven't this repository enabled and then first need to stumble about the bugreport for knowing that the backport packages will solve the issue. any further ideas for a fast fixing in jaunty?

[Reinhard Tartler (siretart)]

bojo42 <email address hidden> writes:

> added "ffmpeg-debian" as the bug is rather fixed there than in the
> "ffmpeg" source package. as this issue is now fixed in debian (thanx to
> all involved) it's now up to fix it in ubuntu too.

That would be me.

> for karmic this should be done with a debian import,

No, the new package needs to be merged properly. I see that I get to
that later this week

> but for jaunty we will need a SRU
> (https://wiki.ubuntu.com/StableReleaseUpdates). as it's a really safe
> small change in debian/control i don't think this should be a big
> deal,

I don't think that this is a so harmless as you claim. I really like to
have it tested in the wild before considering an SRU.

However feel free to work on that in a PPA.

And TBH, I don't understand all the fuzz people are making about
this. It really isn't so hard to remove the unstripped package before
building.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

[Reinhard Tartler (siretart)]

nothing to fix in the 'ffmpeg' source package, only in the 'ffmpeg-debian'

[Reinhard Tartler (siretart)]

I'm working on it in the pkg-multimedia git repository.

[bojo42 (bojo42)]

@Reinhard: regarding my part of the fuzz ;) i can't uninstall unstripped because then i can't compile the plugins i want to. so this can only be done by temporary "corrupting" the package system and AFAIK i can't do this on Soyuz or other builders.

any way i like to ask you if what Fabian wrote at the debian bugreport is true for my/our case:
"Please note that there is no advantage from building packages against libxxx-unstripped. The packages are API/ABI-compatible with their libxxx counterparts. So it is perfectly allright to build packages against libxxx-dev + libxxx and replace libxxx with libxxx-unstripped afterwards. You will still be able to use all the codecs from the fully functional library package."

would that mean i just have to foul the configure stuff to ignore the missing libs and would get the same result as with the unstripped libs?

best regards
bojo42

[Reinhard Tartler (siretart)]

bojo42 <email address hidden> writes:

> @Reinhard: regarding my part of the fuzz ;) i can't uninstall unstripped
> because then i can't compile the plugins i want to.

Please elaborate. What plugins absolutely require the unstripped
variants?

I'm so pedantic on that because if that was true, then it would be
probably an indication that the way we strip indeed causes problems we
didn't think of.

> so this can only be done by temporary "corrupting" the package system

a simple 'apt-get install libavcodec52' will not corrupt anything.

> and AFAIK i can't do this on Soyuz or other builders.

libavcodec-dev is perfectly installable on launchpad's autobuilders.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

[bojo42 (bojo42)]

@Reinhard: MPEG4 Part 2 (MP4V-ES) and H.263+ / H.263-1998 as you can see on http://wiki.ekiga.org/index.php/Compiling_Ekiga

because of that i need the dev and the unstripped packages installed at the same time, but as i said in my last comment: i would like to know if i only need to trick the configure script to set the named plugins for compiling with the stripped ones?

[Reinhard Tartler (siretart)]

bojo42 <email address hidden> writes:

> @Reinhard: MPEG4 Part 2 (MP4V-ES) and H.263+ / H.263-1998 as you can see
> on http://wiki.ekiga.org/index.php/Compiling_Ekiga

How does ekiga check at build time if the h263 encoder is enabled at
run-time? AFAIUI it cannot, and ekiga built against the stripped
packages should magically be able to use the h263 encoder from the
unstripped package as soon as it is installed.

If that is not the case, I'm doing something really insane and definitly
want to know about it.

I guess I need to have a closer look at ekiga then...

> because of that i need the dev and the unstripped packages installed at
> the same time, but as i said in my last comment: i would like to know if
> i only need to trick the configure script to set the named plugins for
> compiling with the stripped ones?

How does the configure script implement that check? Does it really
compile a testprogramm calling av_register_codec(CODEC_H363_ENCODER) or
something and checks the result of the compiled testprogram?

If yes, then that check is utterly broken and really should be
fixed. But that is really a totally seperate bug.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

[bojo42 (bojo42)]

@Reinhard: i now tried it without the unstripped package and i am able to compile the plugin (even though i haven't tested it yet). but i had to trick the configure script so it the if conditions regarding checking for the non free codec in avcodec simply always says yes to compiling it, this of course means the check doesn't go on with the stripped one. for more details i can send you the specific part of the configure script or you grab it from the opal package under plugins (HAVE_H263P is the magic word), but so far it seems you're not doing things very insane ;) i also found an alternative for my case as the discrete plugin directories have make files in them, so i just need to call make directly there and don't have to care about forcing configure's decision. so thank you very much for helping me to understand the whole issue, as i am now able to do the packages on Soyuz :)

@all: to clarify this all means even if the software we compile or package needs the unstripped packages at runtime, it don't or shouldn't need them when compiling. so we only need to make sure the configure stuff doesn't disable compiling of the needed features because we have the stripped packages installed at compiling/building or we have to compile them "manually" some how. for packagers this means you need the dev packages at build-depends and the unstripped at the normal depends in debian/control, so you make sure you at least have the unstripped stuff at runtime.

great i finally got it :) but i would still feel comfortable with letting the dev package optionally depend on the unstripped libs, in case this won't make any unintended troubles.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ffmpeg-debian - 4:0.5+svn20090609-1ubuntu1

---------------
ffmpeg-debian (4:0.5+svn20090609-1ubuntu1) karmic; urgency=low

  * merge from debian. Remaining changes:
    - don't build-depend on libfaad-dev, disabling faad decoder.
    - build arm vfp variant
  * update gbp.conf
  * move gbp.conf to debian/

ffmpeg-debian (4:0.5+svn20090609-1) unstable; urgency=low

  [ Andres Mejia ]
  * Add myself to Uploaders list.
  * Reorder when dh_strip is done so qt-faststart is also
    stripped.
  * Update to control files.
  * Add new confflags for new build dependencies.
  * Use <package>.docs files to add ffmpeg and ffmpeg-doc documentation.
  * Use <package>.docs files for installing documentation.
  * Add comment to 900_doxyfile patch.
  * Add man page for qt-faststart.
  * Bump version in changelog to prepare new release
  * Fix FTBFS for ffmpeg source package with -dev packages (Closes: #527761)
  * Use dh_lintian to install lintian overrides
  * Update comment on fpic-* patches
  * Build-Depend on debhelper (>= 6.0.7~) for dh_lintian.
  * Add lintian overrides for remaining fpic lintian errors.
  * Shorten comment on lintian-overrides.
  * Allow passing in extra confflags, removes the need for fix-fpic
    DEB_BUILD_OPTIONS.
  * Fix FTBFS on kfreebsd. (Closes: #528591)
  * Include patches to allow us to use opencore-amr libraries.

  [ Reinhard Tartler ]
  * remove debian/control.* mechanism
  * improve patch description for debian/patches/100_kfreebsd

  [ Andres Mejia ]
  * Add lintian overrides for ffmpeg-debian source warnings.
  * Only use .svnrevision if it's readable.
  * Update source lintian-overrides for modifications to debian/rules.
  * Add fix for FTBFS for GNU Hurd OS. Thanks Marc Dequènes.
    (Closes: #530436)

  [ Felipe Sateler ]
  * Don't add -unstripped to the unstripped variant version number
    in debian/README.upstream-upgrade.
  * In the same file, pass explicit version to git-import-orig

  [ Fabian Greffrath ]
  * Cleaned up debian/watch file.
  * Add notes why we no longer strip the orig.tar.gz.

  [ Andres Mejia ]
  * Fix watch file to ignore daily snapshots.
  * Make get-orig-source.sh executable.

  [ Reinhard Tartler ]
  * add patch for qtrle encoding (Closes: #530016)
  * Enable xvmc support by adding libxvmc-dev to build dependencies
  * really add libopenjpeg-dev to build depends, actually enabling
    the openjpeg decoder.
  * reorganise README.Debian for the new plan [tm]
  * no longer strip the source on upstream upgrades
  * Imported Upstream version 0.5+svn20090609
  * adjust notes in README.upstream-upgrade for the now unstripped
    debian source package
  * remove hack to build with stripped sources
  * bump standards version, no changes needed

ffmpeg-debian (4:0.5+svn20090420-2) unstable; urgency=low

  * debian/control: fix dependencies for libavutil-dev and libavfilter-dev
    so that they can be used with the unstripped variants properly.
  * debian/rules: set nooptflags only for relevant architectures.
  * explicitly disable 'dangerous' encoders on the --configure line.
  * fix SHLIBS_VERSION in debian/rules (Closes: #527350).

ffmpeg-debian (4:0.5+svn20090420-...

[benchang (ben-bcchang)]

Hi,

I'm not a dev or maintainer, but have an end user example case. From my reading of this thread my understanding is that it'll be fixed in Karmic - woder if you could tell me if that's correct.

Kdenlive (video editor) requires libav*-unstripped in order to render and export videos
OpenCV (computer vision library) depends on libav* (stripped), so you cannot have both packages installed.

Is that now fixed in the ffmpeg-debian package, or is it rather that it should be fixed by the maintainers of one or the other or both of the example packages?

thanks.

[Reinhard Tartler (siretart)]

benchang <email address hidden> writes:

> Is that now fixed in the ffmpeg-debian package

yes, it is fixed in karmic

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

[Paul Gevers (paul-climbing)]

> Kdenlive (video editor) requires libav*-unstripped in order to render and export videos
> OpenCV (computer vision library) depends on libav* (stripped), so you cannot have both packages installed.

This bug is about an other problem. libxxx-dev is the package that these
programs need to BUILD. What you are talking about is what they need to
WORK. As far as I understand it BOTH packages should depend on
"libav* | libav*-unstripped" because these libraries are api/abi
compatible, but just provide more ore less codecs (depending on what you
are allowed/willing to install). So these programs will BOTH function
with either of the packages, but depending on which one you have, they
can use a limited set or all codecs available.

Please file separate bugs for both packages requesting this (at least
for OpenCV).

Paul

[benchang (ben-bcchang)]

Got it. Actually I described the issue incorrectly in my example: the problem
is in fact with compiling, not with dependencies in just using the packages.
OpenCV is largely used for development, and it's libcv-dev that depends on
libav*-dev, which is not satisfied by libav*-unstripped.

So if (in karmic) libavcodec-dev can now be satisfied by having libavcodec-
unstripped, etc., then it's all good. thanks!

On Tuesday 11 August 2009 02:26:37 am Paul Gevers wrote:
> > Kdenlive (video editor) requires libav*-unstripped in order to render and
> > export videos OpenCV (computer vision library) depends on libav*
> > (stripped), so you cannot have both packages installed.
>
> This bug is about an other problem. libxxx-dev is the package that these
> programs need to BUILD. What you are talking about is what they need to
> WORK. As far as I understand it BOTH packages should depend on
> "libav* | libav*-unstripped" because these libraries are api/abi
> compatible, but just provide more ore less codecs (depending on what you
> are allowed/willing to install). So these programs will BOTH function
> with either of the packages, but depending on which one you have, they
> can use a limited set or all codecs available.
>
> Please file separate bugs for both packages requesting this (at least
> for OpenCV).
>
> Paul

[MMarking (cpt-mocha)]

Just to add my experience, I ran into this problem when trying to compile xine-vdpau. I have dvdstyler installed and it depends on the unstripped packages. However, xine-vdpau won't compile without the libavxxxx dev packages, so it was a catch 22.

Anyway, I found that by building my own ffmpeg from source and configuring with --enable-shared and installing to /usr/local, then I was finally able to compile xine-vdpau. I assume this is because compiling ffmpeg with --enable-shared installs the shared libs to /usr/local, and xine-vdpau looked in there for the necessary lib files that would have otherwise been provided by libavcodec-dev, etc..? Just a guess, I'm not an expert on these matters.

[TonyKnott (tonyknott-deactivatedaccount)]

Ok, it seems the problem is solved for dynamic compilation, but what about static compilation?

Theoretically, the -dev packages also provide static versions of the libraries. Which versions are currently being provided, the stripped or the unstripped ones?

[Reinhard Tartler (siretart)]

TonyKnott <email address hidden> writes:

> Ok, it seems the problem is solved for dynamic compilation, but what
> about static compilation?
>
> Theoretically, the -dev packages also provide static versions of the
> libraries. Which versions are currently being provided, the stripped or
> the unstripped ones?

That is indeed an unsolved issue. Fortunately, it is not relevant for
ubuntu as distribution, as we don't want any package to link statically
against ffmpeg.

For your own applications I'd strongly suggest to compile FFmpeg HEAD
from hand and link (statically) against that version, instead of against
the system FFmpeg version.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

[TonyKnott (tonyknott-deactivatedaccount)]

In this case, shouldn't the static versions be completely removed from the -dev packages? By looking at the package contents, it seems they are still there and this might be confusing for the users, who won't know if they are the stripped or the unstripped versions.