Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 168633 - media-libs/mlt does not register itself for revdep-rebuild
Summary: media-libs/mlt does not register itself for revdep-rebuild
Status: RESOLVED UPSTREAM
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Gentoo Media-video project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-27 20:53 UTC by Roberto Castagnola
Modified: 2007-12-28 10:16 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roberto Castagnola 2007-02-27 20:53:51 UTC
After updating media-video/ffmpeg, /usr/share/mlt/modules/libmltavformat.so was broken (libavformat.so.50 replaced by libavformat.so.51) but revdep-rebuild didn't found it because media-libs/mlt doesn't register /usr/share/mlt/modules dir for revdep-rebuild.

Proposed patch:
--- /usr/portage/media-libs/mlt/mlt-0.2.2.ebuild        2006-09-20 01:35:56.000000000 +0200
+++ mlt-0.2.2.ebuild    2007-02-27 21:30:30.000000000 +0100
@@ -73,4 +73,12 @@
        dodir /usr/share/${PN}
        insinto /usr/share/${PN}
        doins -r demo
+
+       # environment variables
+       cat <<EOF > ${T}/50-mlt-revdep
+SEARCH_DIRS="/usr/share/${PN}/modules"
+EOF
+
+       insinto /etc/revdep-rebuild
+       doins ${T}/50-mlt-revdep
 }
Comment 1 Alexis Ballier gentoo-dev 2007-04-15 16:32:59 UTC
the problem is that according to the fhs ( http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA ) :
The /usr/share hierarchy is for all read-only architecture independent data files


and shared libs are definitely not architecture independant :/
Comment 2 simon 2007-08-30 20:18:13 UTC
I may have had a similar problem after upgrading my whole system, which also upgraded mlt-0.2.3 to mlt-0.2.4.

Although revdep-rebuild didn't complain about anything ("Dynamic linking on your system is consistent..."), running 'inigo xyz.mpeg' gave me:

'Failed to load plugin: libmlt.so.0.2.3: cannot open shared object file: No such file or directory'

I think that the error message comes from ffmpeg (?).
Indeed, there was no 0.2.3 on the system:
~ $ equery belongs /usr/bin/inigo
[ Searching for file(s) /usr/bin/inigo in *... ]
media-libs/mlt-0.2.4 (/usr/bin/inigo)

Only after re-emerging mlt (and mlt++) things worked fine.
Comment 3 Roberto Castagnola 2007-12-28 10:16:41 UTC
(In reply to comment #1)
> the problem is that according to the fhs (
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA
> ) :
> The /usr/share hierarchy is for all read-only architecture independent data
> files
> 
> 
> and shared libs are definitely not architecture independant :/
> 

According to upstream TODO list (http://www.mltframework.org/twiki/bin/view/MLT/ToDo) module binaries will be moved to libdir/mlt, so I suppose to close this bug as UPSTREAM