I recently caught the X upgrade in testing and discovered that none of
the available drivers would work. I've since fixed that, but it got me
wondering what a good way to dowgrade all of X was.

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.

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.

Any other ideas?

Footnote on the X problems. The open-source nvidia driver has never
worked for me, and the upgrade broke the closed one. However, the fix
at the bottom of Debian bug 420177 worked for me. Thanks to Brice
Goglin for drawing it to my attention. The vesa driver sort of worked,
but characters in emacs came out as little squares.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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?

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"


>
> 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.

>
> 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
downgrade. 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.

A

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGcfSQaIeIEqwil4YRAgrfAJ0TAMfRcGH+MQ/O6mEUeLMMCpdw7gCgrwwc
xeMkGrDEUj5aEKNN212IrhY=
=MHqS
-----END PGP SIGNATURE-----

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


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org