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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
