Feature #4708
Bug #4738: replace liben50221 (dvb-apps dependency)
enabling static linked dvb-apps libs
0%
Description
Hi,
out of my view tvh uses this libs from the dvb-apps:
. lib/libdvbapi - Interface library to digital TV devices
. lib/libucsi - Fast MPEG2 Transport Stream SI table parsing library
. lib/libdvben50221- Implementation of a Cenelec EN 50221 CAM stack
Under Debian the package dvb-apps has the disadvantage that it hat to much dependencies to other packages which are not realy needed on the runtime system. Therefore a static including of these libs could be a good solution for a smaller server setup.
br
Alfred
History
Updated by saen acro about 7 years ago
+1
in CentOs there is not dvb-apps
there is lot of git-s with optimisations for signal measurement
my tvh stb image have footprint of 23Mb
Updated by Alfred Zastrow almost 7 years ago
Hi,
I want to advertise the feature request a bit and therefore I did some comparisons:
Static linking of these libs increases the tvh binary size by only 36 k.
The install footprint by not installing the dvb-apps on a runtime system (headend :-) ) get's reduced by almost 12 MB.
dvb-utils (3.090 k)
-> depends on
- dtv-scan-tables (7.980 k), a doubble install, because they are already included in the tvh package
- libzvbi0 (727 k)
-> depends on
- libzvbi-common (172 k)
The change is pretty easy:
root@tvhbuilder:~# diff -u tvheadend.orig/configure tvheadend/configure --- tvheadend.orig/configure 2017-11-16 18:14:47.724179829 +0100 +++ tvheadend/configure 2017-11-20 20:25:32.838559889 +0100 @@ -647,7 +647,7 @@ # if enabled linuxdvb; then if enabled libdvben50221; then - LDFLAGS="$LDFLAGS -ldvben50221 -ldvbapi -lucsi" + LDFLAGS="$LDFLAGS /usr/lib/libdvben50221.a /usr/lib/libdvbapi.a /usr/lib/libucsi.a" enable linuxdvb_ca fi fi root@tvhbuilder:~# diff -u tvheadend.orig/debian/control tvheadend/debian/control --- tvheadend.orig/debian/control 2017-11-09 17:50:24.858059926 +0100 +++ tvheadend/debian/control 2017-11-20 20:44:47.997107824 +0100 @@ -7,7 +7,7 @@ Package: tvheadend Architecture: any -Depends: ${shlibs:Depends}, libavahi-client3, zlib1g, liburiparser1, dvb-apps, bzip2 +Depends: ${shlibs:Depends}, libavahi-client3, zlib1g, liburiparser1, bzip2 Recommends: xmltv-util Enhances: showtime Replaces: hts-tvheadend
License is also not a problem. dvb-apps are GPL2 or later.
br
Alfred
Updated by Mono Polimorph almost 7 years ago
Hi,
I agree with multiple compile configurations. I really like static linked binaries... not for every case, but useful in several environments.
So, if the developers can upgrade the build (configure.sh) for supporting this option I suggest to do it.
Updated by Jaroslav Kysela almost 7 years ago
It appears that we need to modify debian/control dynamically. That's the probably main issue with this proposal. Also, I do not think that using of the hardcoded paths /usr/lib is good (configure), too.
Updated by Mono Polimorph almost 7 years ago
Jaroslav Kysela wrote:
It appears that we need to modify debian/control dynamically. That's the probably main issue with this proposal. Also, I do not think that using of the hardcoded paths /usr/lib is good (configure), too.
Right! However, as you're supporting the "fmpeg_static", "hdhomerun_static", etc... then you can support "dvb-apps_static". This can be done adding "dvben50221_static", "dvbapi_static" and "ucsi_static". However, in this case you need to fetch the source packages of these three libraries.
I don't know if this is a good idea. But in any case I like to have the options for static linking.
Updated by Em Smith almost 7 years ago
Surely the problem in this case is with Debian/Ubuntu package and should be fixed there to benefit other people too? As Jaroslav says, hard-coding the paths is problematic, e.g., FreeBSD installs in /usr/local.
The dvb-apps seems to be a catch-all of antiquated programs: does anyone really use keymaps for av7110?
However, it does contain dvbdate, femon and a few useful tools.
Have you tried raising an issue with the maintainers to split up the package?
Ideally it should be split like other Debian packages in to a dvb-apps -lib, a -dev package, a recommend for dtv-scan-tables (rather than a requirement), split documents and test harnesses out, and probably split gnutv in to a separate package too since does anyone even use it?
Then we can just depend on the new -lib and -dev packages which will be tiny.
Updated by saen acro almost 7 years ago
Kick off dtv-scan-tables they are old and not actual with big misses.
Better #4379 there is also scrapers.
Updated by Mono Polimorph almost 7 years ago
Em Smith wrote:
Surely the problem in this case is with Debian/Ubuntu package and should be fixed there to benefit other people too? As Jaroslav says, hard-coding the paths is problematic, e.g., FreeBSD installs in /usr/local.
Ummm... The user that has created this issue commented about a problem with Debian/Ubuntu. However, include support for "static" linking is great. And the TVH project has support for it for several packages (libffmpeg, libhdhomerun, etc.). So add support for static "dvb-apps" through static "libdvben50221", "libdvbapi" and "libucsi" seems to be reasonable.
And, no, the solution can't be the use of static "/usr/local/*.a" linking. This point seems to be very clear.
Updated by Alfred Zastrow almost 7 years ago
The answer from Mono Polimorph could also be my answer. Source pulling an compiling/linking inside the tvh tree is a better way.
The main problem from the dvb-package with it's dependencies, that it brings a lot of useless bits to the runtime system, cannot be solved inside tvh.
If the dependency is there += 12MB.
br
Alfred
Updated by Em Smith almost 7 years ago
I never suggested linking against /usr/local/*.a.
What I said was that the dvb-apps package does not conform to modern standards where programs are split off in to separate packages, and where optional configuration files are a recommendation rather than a requirement.
I then asked if anyone had asked the maintainer of the package about splitting the package so that it would benefit every user of the package.
If you don't want dtv-scan-tables then don't build them. Simply pass "--disable-dvbscan". If you don't want the dvben dependencies then pass "--disable-dvben50221".
Downloading and bundling a large source package, full of things people will never require, and all its build dependencies (taking much more disk space than the pre-compiled .deb) seems a bad idea to me.
Are there really systems that are so constrained in disk space that a couple of megabyte is a major deal? Especially when the program itself generates gigabyte files so huge storage must normally be available.
Updated by Jaroslav Kysela almost 7 years ago
- Status changed from New to Rejected
- Parent task set to #4738