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 <>:
> > 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
> > 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, 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!

> klaumi
> -----------
> Klaumi Klingsporn 
> mail:
> web:


Reply via email to