Re: Repo mix-and-match hit parade
Posted: 2015-12-21 05:13
You could backport your own shiny new stuff, or take advantage of others that know how to do it.
The MX 15 repo in my sig started out in plain vanilla Jessie; we've added more updates as time has gone on, but it's still very close to a Jessie + jessie-backports base. We've decided to port over jessie-backports packages as necessary, due to some nasty breakages that wheezy-backports created over the past few years, some of which the maintainer took months to fix, such as the Qt 5 backport.
I learn something new all the time..today, that having libgstreamer1.0-dev installed while backporting upstream's VLC 2.2.1-5 will cause the package to have a build failure. This is due to the build silently creating an extra libgstdecode.so plugin library that the Debian package install system does not account for when that package is installed. Making that -dev package a "Build-Conflicts:" in debian/control solves that issue. The other method is to make it a Build-Depends and add that .so file to the debian/vlc-nox.install.in file...it's the packager's choice.
The MX 15 repo in my sig started out in plain vanilla Jessie; we've added more updates as time has gone on, but it's still very close to a Jessie + jessie-backports base. We've decided to port over jessie-backports packages as necessary, due to some nasty breakages that wheezy-backports created over the past few years, some of which the maintainer took months to fix, such as the Qt 5 backport.
I learn something new all the time..today, that having libgstreamer1.0-dev installed while backporting upstream's VLC 2.2.1-5 will cause the package to have a build failure. This is due to the build silently creating an extra libgstdecode.so plugin library that the Debian package install system does not account for when that package is installed. Making that -dev package a "Build-Conflicts:" in debian/control solves that issue. The other method is to make it a Build-Depends and add that .so file to the debian/vlc-nox.install.in file...it's the packager's choice.