Re: How to install qt5 on Wheezy, and is that even a good idea?
Andrei POPESCU <andreimpopescu@gmail.com> writes:
> On Sb, 23 aug 14, 13:43:50, Mark Carroll wrote:
>>
>> In my /etc/apt/preferences.d/preferences I have,
>>
>> Package: *
>> Pin: release a=stable
>> Pin-Priority: 600
>
> You are increasing priority of stable, from 500 to 600, why?
I can't remember; it never seemed to be a problem anyway. Maybe I wanted
to leave more room below it!
(Broadly, the file arises from when I grudgingly had to change from
dselect's FTP method because repositories I wanted were being offered
HTTP-only: I probably read the apt-get manpage back then approximately
once and found that similar files have worked fine since.)
>> and also,
>>
>> Package: *
>> Pin: release a=testing
>> Pin-Priority: 50
>>
>> Package: *
>> Pin: release a=unstable
>> Pin-Priority: 40
>
> This will make both testing and unstable have a lower priority than
> installed packages. In practice this means you will *never* receive
> updates to packages you installed from testing or unstable. Not even
> security updates.
Yes, I want to give chance for stable updates and suchlike to catch up
with them over time: I generally don't want to be using packages from
testing and unstable unless I have to, and I'd like them not to stay
ahead in the longer term. Security updates aren't an issue because I
subscribe to debian-security-announce and manually make sure that
anything applicable does get updated, and so far I don't think that's
been anything I actually had from later than "stable".
(Annoyingly, apt seems to get upset if I want to force the later
packages into trying to use older dependencies to see if they work well
enough, so I can end up pulling in more later packages than I want to,
but it tends to work well enough to uncompress the package and tweak
its metadata and install that adjusted version instead.)
> If unstable has to be used (are you sure? packages should migrate to
> testing within days anyway) then yes, it makes sense to pin it to
> something lower than 100.
I guess they don't always so quickly, because I do try the "testing"
version before the even later ones, but I certainly do sometimes end up
having to use the "unstable" or, admittedly rarely, experimental. My
guess is that "unstable" might be for a couple of reasons: something it
interacts with, some service on the Internet or whatever, changed, and
the package is just suddenly unexpectedly broken without a patch that
quickly appeared upstream; or, I had a bug where the package maintainer
didn't really care unless I could confirm it also occurs with the
latest. Actually, fairly often I have software that just really doesn't
work so well, and I try progressively later versions to see if I am
lucky enough to hit one that has the bug or annoyance actually fixed,
which of course sometimes has me go all the way before finding it isn't.
> Beware though that the package will not be updated until testing has a
> higher version. This is especially important in case of security
> upgrades.
I actually usually assume that "testing" doesn't much enjoy security
upgrades: they'll hit "stable" and "unstable" first, so that's partly
why I use the mailing list to help make sure I'm on top of things. My
system's core services are pretty much all from "stable" anyway, it's
usually just the occasional utility or connector that isn't.
> Also, as a general remark, it's much better to use code-names
> everywhere, to avoid surprises whenever there is a release.
That means I have to change them all when there is a new major release,
of course, if I want to upgrade! Though, while in the past I have always
pretty much done so automatically, in this case you might be right: I'm
keeping out of the systemd debate, but I certainly don't want to switch
to jessie until I see that people are generally finding it perfectly
viable to avoid systemd. (If it helps, I don't think I need any GNOME
stuff since I stopped using Ekiga.)
-- Mark
Reply to: