Thanks, Klaumi, inline On Mon, Feb 19, 2018 at 07:36:47PM +0100, Klaumi Klingsporn wrote: > Am / On Mon, 19 Feb 2018 17:28:45 +0100 > schrieb / wrote Toerless Eckert <[email protected]>: > > > The whole reason why i got into the trouble of adding > > deb-multimedia as a repo was to be able to install > > avidemux. It is not listed in your above list of > > DebianMultimedia packages, but it shows up in > > https://blends.debian.org/multimedia/tasks/video although > > that page leaves me even more confused as to how i would > > be able to install it without deb-multimedia because it > > just says "Debian package not available", and relase > > "VCS" (no idea what VCS is). > > 1. > There was an attempt to build a debian-avidemux-package in > 2012 (Bug#203211: RFP: avidemux), which wasn't successful, > but this may be the reason for this.
Hmm... so "blends" somehow tracks even historic attempts and displays them ? I guess i have to look carefully for any dates shown to see whats obsolete. > 2. > The problem with deb-multimedia is that it's based on some > multimedia-programs and libraries (like ffmeg, libx264 etc) > which are non-free and not in Debian, or that are also in > Debian, but in different Versions. To make sure, that the > people using his repository only get his packages, Marillat > gives them a higher Version-Epoch. But this has the result, > that you have to install his versions of many packages to > install even the smallest peace of software, for which all > dependencies also could be resolved in the Debian archives. Oh... that sounds like a good cautionary tale to write into the wiki. Its definitely a bad approach, but i am not sure if there was a better one for such a repository with the dependency management of debian. I do not understand tracking of "features" in debian with dependencies. I ahve been using gentoo so far, and there, a new package may require features in dependencies you had not previously compiled in, resulting in the need to recompile a lot of dependencies with that feature. If debians approach is single binary per packet version, with the "most likely required feaures" compiled in, then i can see how thats limiting the ability to easily leverage main repo dependencies. > 3. > So: If you really want to use deb-multimedia.org, you may do > this by apt and pinning the repository to -900 > in /etc/apt/preferences. I guess -900 means lowest priority ? But how would that change the way dependencies are being pulled in - especially if those from deb-multimedia have higher epochs and thats part of the dependency ? > But the better way is to do it 'by hand' (downloading > packages and install via dpkg). If this isn't possible, in > most cases it's possible to download Marillats > source-packages, adjust the versions of the dependencies in > the Debian/control-file and the version of the package in > Debian/changelog and recompile/rebuild the package: > fakeroot dpkg-buildpackage > > E.G.: avidemux depends on libaften0 which is not in Debian > (because non-free) but can be used from Marillat without any > dependencies. All other dependencies (libx264, libx265) can > be resolved within Debian, but you have to adjust the > versions in new-build avidemux-packages. Stupid beginner question: Whats the bar for a package to make it into debians "non-free" repo ? And is that bar the reason for libaften0 not to be in there, or is it just lack of ressources/interest ? Given how libaften doesn't seem to be evil proprietary software but just has a messy mix of licenses i wonder... > Hope this helps! Definitely. Thanks! Toerless > > klaumi > > > ----------- > Klaumi Klingsporn > mail: [email protected] > web: www.klaumikli.de -- --- [email protected]
