Florian Kulzer wrote:
On Thu, Sep 20, 2007 at 14:20:27 +0100, Bob wrote:
Hi, I just tried Lenny and MergeFB is busted for that combination of
xserver-xorg-core and xserver-xorg-video-ati, for the moment the fix is
install xserver-xorg-video-ati from experimental, so I have to delve in the
world of apt-pinning.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=420628
If I install a package from experimental or sid, is there any way I can
track it's progress down the tree? that is to say, in some months time,
when a fix or feature has trickled down to Lenny, I don't necessarily want
to be running whatever even newer version is in experimental or sid, which
may well have problems of it's own. Failing that how do you downgrade a
package from the one in sid to the one in testing?
You don't have to pin anything; apt assigns a very low priority to
"experimental" packages by default:
$ apt-cache policy xserver-xorg-video-ati
xserver-xorg-video-ati:
Installed: 1:6.6.192-1
Candidate: 1:6.6.193-3
Version table:
1:6.7.192-4 0
1 http://ftp.de.debian.org experimental/main Packages
1:6.6.193-3 0
500 http://ftp.de.debian.org unstable/main Packages
*** 1:6.6.192-1 0
100 /var/lib/dpkg/status
1:6.6.3-2 0
500 http://ftp.de.debian.org stable/main Packages
500 http://ftp.de.debian.org testing/main Packages
As you can see, the experimental version is ignored as an installation
candidate even though it is the newer than the one in Sid.
A priority of 1 means that the package will only be installed if there
is no installed version of that package; see "man apt_preferences". In
other words, an experimental version of a package will never
automatically displace an already installed version of that same package
(even if the installed version itself came from experimental). When a
newer version of that package comes to Lenny, on the other hand,
apt(itude) will automatically replace the older version if you use
"upgrade". If I understand you correctly, this is what you want.
Perfect, I understood most of the pinning and prioritys, I didn't
realise that after installing a package from sid or experimental it
wouldn't then track the version of that package in that non-release, the
more I learn about apt the more I like it.
Therefore you can simply add an "experimental" repository to your
sources list and run
apt-get install -t experimental xserver-xorg-video-ati
to install the new ati driver. You system will continue to have that
driver until a newer version comes to Lenny or until you ask for a newer
experimental one by using the "-t experimental" switch again.
I myself prefer to use aptitude's interactive interface when I mess
around with (experimental) packages since this gives me better control
and a quicker overview of dependency issues. (The "-t" option works the
same for aptitude.)
Please note, however, that all my remarks only concern the package
management; I have no ideas about possible problems of the experimental
driver itself. Also, there can be complications related to sets of
interdependent packages, but you would run into the same issues when
using pinning. The apt-cache command is always helpful to get a feeling
for what is going on.
Ah yes apt-cache depends is very useful, it took a while to find a
collection of packages for my LAMP gallery2 box that didn't use any
apache2 related stuff.
apt-cache depends libapache-mod-php5 apache php5 mysql-server-5.0 netpbm
ffmpeg dcraw jhead zip unzip php5-mysql php5-gd imagemagick
though for some reason if you don't have libapache-mod-php5 at the front
of the list when you come to install, it will pull in
apache2-mpm-prefork, apache2.2-common and libapache2-mod-php5 which it
won't if it is at the front.
In the /etc/apt/preferences file, is there any way of pining to a release
rather than to stable or testing? I've got used to using the release
codename in my sources.list so that I don't upgrade until I change the link
in sources.list and issue an apt-get dist-upgrade.
It seems in the preferences file an entry like
Package: *
Pin: release a=etch
Pin-Priority: 700
doesn't work and you have to use a line like,
Pin: release a=stable
Is there a way round this inconsistency?
I don't know of any, but I have never really investigated this issue
since it does not concern real men (Sid users) like me. In the absence
of a general solution I hope that what I wrote above is at least helpful
for your specific problem.
I suppose it's only an issue at around the time of a new release. It
would be nice if the preferences file worked in the same way as
sources.list and supported both.
I'm just about to start admining a bunch of remote debian machines for
various family members, I'll probably have apt-get update, upgrade and
maybe even dist-upgrade running as cron jobs or something similar, I'm
yet to look into auto update tools, they'd be running etch with versions
of pidgin, ekiga and OOo from lenny or sid and I don't want them being
auto upgraded to lenny when he goes stable.
Thanks for your response.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
