Tvheadend

+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

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

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.

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.

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.

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.

Kick off dtv-scan-tables they are old and not actual with big misses.
Better #4379 there is also scrapers.

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.

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

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.