Re: Pining for Qt 5.4
> My guess is that in your previous attempt you added experimental to
> your sources.list but didn't pin the release to a negative number, so
> other packages might have automatically crept in in some cases,
> screwing up your system that way. But if you pin experimental to a
> negative number, you have to explicitly pin those packages that you
> want back to a positive number in order for APT to consider them as
> candidates for your system.
Actually, even though I implicated it, I never installed experimental
stuff on my system. And "Pining" is not "Pinning" -- I learned the
latter word from you and the former one from Monty Python (the
sketch with the dead parrot). "Pining for s.th." means
something like "desiring deeply (in a heartfelt way)".
What I _did_ do prior to said trauma was
[!!!KIDS, DONT TRY THIS AT HOME!!!]:
deb http://www.deb-multimedia.org jessie main non-free
to my /etc/apt/sources.list and then bray
The effects were akin to what I imagine may happen if you simply set
your whole system to experimental. Hundreds of packages were pulled
in and, for instance, sound was broken.
Having /home separated from the rest of the system and only just come
from another distro I decided it was simplest to reinstall. This was
last Christmas and I have been happy ever since, successfully avoiding
To the issue: My acute Qt problem is solved since I finally found
I could install Qt 5.4 locally in home and then have CMake find it
setting the CMAKE_PREFIX_PATH accordingly (i.e. in my case to
the Widgets package pulling in all other dependencies).
I will keep "pinning" and the "apt-cache policy" in mind though and
come back to your mails when I ever need a specific
testing/experimental package without being ready to flame up my whole
Thanks again to you and all others answering my question!
P.S.: I already unsubscribed from this mailing list again because
I felt it was really spamming my mailbox with lots of stuff I
did not even understand what people are talking about. Is there a way
to configure it thus that it only forwards answers to the user's
own posts to that user's mailbox?
On 02.05.2015 16:57, Christian Seiler wrote:
> On 05/02/2015 04:00 PM, Markus-Hermann Koch wrote:
>> thanks for your detailed answer!
>> Sigh. I am still hoping to avoid experimental on this one (being
>> already traumatized from past experiences culminating in complete
>> reinstallation into my now clean 'unstable' system with its single
>> media package libdvdcss2).
> Well, if you do pin experimental packages to -1 by default, APT will
> never install them, even if you ask it to.
> For example, if I want to install libkf5config-dev (only in
> experimental so far), have experimental in my sources.list.d but also
> pinned to -1, using APT has the following result:
> # apt-get install libkf5config-dev
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package libkf5config-dev is not available, but is referred to by another
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> E: Package 'libkf5config-dev' has no installation candidate
> This means that no packages from experimental can be installed by
> default, you have to explicitly pin them again to make certain packages
> On my own box, I did exactly the steps I wrote in my previous mail to
> test the installation of Qt 5.4 (I'm running Jessie, Qt5 previously not
> installed at all), and running apt-get install qt5-default it installed
> Qt5 packages from experimental, but all other packages from Jessie.
> This works now because Qt 5.4 doesn't have any dependencies on stuff
> that's only in experimental, so you will currently get ONLY Qt 5.4, but
> everything else will be from other suits.
> Now, if at some point you want to install something from experimental
> that does have additional deps on other experimental packages, you will
> have the following stuff happen:
> - first you just pin the packages you want themselves to 500
> - then you try to install them with APT. that will tell you that it
> can't resolve dependencies (and it will also tell you which ones)
> - then you take a look at the dependencies you'd need from experimental
> and see if you think you can live with that - if so, just add them
> to the list of packages pinned to 500 (if you pin by releaese, you
> can add the deps to the same list as the original package, if you pin
> by version, you need to create a new block with the new version
> My guess is that in your previous attempt you added experimental to your
> sources.list but didn't pin the release to a negative number, so other
> packages might have automatically crept in in some cases, screwing up
> your system that way. But if you pin experimental to a negative number,
> you have to explicitly pin those packages that you want back to a
> positive number in order for APT to consider them as candidates for your
>> Still: If I can make your priority based updating work and if it
>> does not require pulling too important other testing/experimental
>> libraries into my system I will give it a shot.
> As I said: currently Qt 5.4 is installable without any deps on stuff
> that's not already in unstable.
> If you understand what pinning does (and what different priority ranges
> mean), then you can use that to selectively install packages from
> different suits / different repositories without having the risk that
> other packages from those repositories 'contaminate' your system. You
> only have to keep in mind that 'apt-cache policy' is your friend if APT
> complains about stuff, because with that you can check what's going on.