Re: how to downgrade a suite of packages?
On Thu, 2007-06-14 at 19:08 -0700, Andrew Sackville-West wrote:
> On Thu, Jun 14, 2007 at 05:25:17PM -0700, Ross Boylan wrote:
>
> [...]
>
> >
> > The advice I've found on the list gave methods that were good for
> > downgrading a package, or the whole system, but seem awkward with a
> > whole set of packages (I realize with enough time I could write a script
> > that would get all the package names and do it for me). I tried this
> > in /etc/apt/preferences
> > Explanation: Downgrade to X I can use
> > Package: xserver-xorg-*
> > Pin: release a=etch
> > Pin-Priority: 1200
> >
> > Package: xorg-*
> > Pin: release a=etch
> > Pin-Priority: 1200
> >
> > but it didn't seem to work (and the man page doesn't exactly suggest it
> > should). I was using aptitude.
>
> what did it do?
It acted the same as it did without them: it didn't try to downgrade the
packages.
>
> in fairly recent history (say 6 months) we've discussed the release
> names and their usage in the apt system. I don't recall the outcome of
> that discussion and am too lazy to look. But a quick scan of the
> apt_preferences man page suggests (since the examples only use this)
> that you need to specify
>
> Pin: release a=stable
>
> instead of "etch"
My sources.list uses etch; I wonder if that would mix with stable in
preferences.
In general, the man page for apt_preferences is strong on examples, but
kind of weak on specifying exactly what you can put in the file and what
it means. My doubts about Package: xorg-* reflect that too.
>
>
> >
> > Before that I tried selecting the xserver-xorg meta-package and
> > downgrading it, but it didn't take anything else with it (since it
> > probably has a lot of >= requirements, the newer ones make it happy
> > too).
> >
> > I considered removing X, but that poses the same problem of identifying
> > all the packages and the extra problem that it would probably remove
> > most of my packages with it.
>
> yeah. That's not fun, though if you go outside of aptitude and use
> apt-get, you could probably remove all of X without taking all of your
> DE with it. apt-get is not as poicky about leaving orphans, and your
> options to force behavior are better.
apt-get and aptitude are only semi-aware of each others' existence
(e.g., if you apt-get install stuff aptitude thinks its just a random
package and tries to clean it out, or at least it did a couple years
ago). I suppose in this case that might be an advantage.
>
> >
> > Any other ideas?
>
> When running testing, I think it is very wise to keep local backups of
> your debs from /var/cache/apt/archives so that you can easily
I have those in the cache.
> downgrade.
But it stilll doesn't make for easy downgrade, because of the problem of
identifying packages.
I suppose even if I did dpkg -i the appropriate packages I would still
have the problem of convincing aptitude to leave them alone. So I guess
the script that did dpkg -i would need to issue aptitude hold commands
as well.
> Especially once testing has moved more than a couple
> versions from stable. If you've moved say 6 ot 8 versions from stable
> and then try to downgrade parts of your system to stable, you're more
> likely to run into problems. If you just need to back up one version,
> its nice to have the .debs sitting around. IOW, avoid clean and
> auto-clean and have plenty of /var space.
>
I figured since I just was running with the prior version (from testing)
and the upgrade didn't seem to have messed with my config, things would
run if I could get the packages downgraded.
Fortunately I seem to be doing OK with the upgrade + the nvidia
work-around.
Ross
Reply to: