aptitude -t unstable install mencoder
aptitude -t unstable install mencoder
apt-get -t unstable install durep apt-get -t unstable install fetchyahoo apt-get -t unstable install gotmail apt-get -t unstable install checkgmail
$ apt-get -t unstable install fetchyahoo The following packages will be upgraded: fetchyahoo Need to get 39.1kB of archives. After unpacking 8192B of additional disk space will be used. Get:1 http://debian.yorku.ca unstable/main fetchyahoo 2.10.2-1 [39.1kB]
$ apt-cache policy fetchyahoo
fetchyahoo:
Installed: 2.10.2-1
Candidate: 2.10.2-1
Version Table:
*** 2.10.2-1 0
40 http://debian.yorku.ca unstable/main Packages
100 /var/lib/dpkg/status
2.8.6-5 0
900 http://debian.yorku.ca sarge/main Packages
$ apt-cache policy gotmail
gotmail:
Installed: 0.8.2-3
Candidate: 0.8.2-3
Version Table:
0.8.9-1 0
40 http://debian.yorku.ca unstable/main Packages
*** 0.8.2-3 0
900 http://debian.yorku.ca sarge/main Packages
100 /var/lib/dpkg/status
apt-get -t unstable install gotmail
$ apt-cache policy gotmail
gotmail:
Installed: 0.8.9-1
Candidate: 0.8.9-1
Version Table:
*** 0.8.9-1 0
40 http://debian.yorku.ca unstable/main Packages
100 /var/lib/dpkg/status
0.8.2-3 0
900 http://debian.yorku.ca sarge/main Packages
Backports are recompiled packages from testing (mostly) and unstable (in a few cases only, e.g. security updates), so they will run without new libraries (wherever it is possible) on a stable Debian distribution.
I recommend you to pick out single backports which fits your needs, and not to use all backports available here.
Add this line
deb http://www.backports.org/debian/ sarge-backports main
to your /etc/apt/sources.list, and these lines
Package: * Pin: release a=sarge-backports Pin-Priority: 200
to your /etc/apt/preferences. That will _deactivate_ all packages from backports.org. To install a package (e.g. mutt), use
apt-get -t sarge-backports install mutt
or
apt-get install mutt/sarge-backports
if the previous command fails.
This is easier when the package requires additional backports.
Date: Sat, 1 May 2004 14:36:17 Cc: debian-user@lists.debian.org
> ... there's this error message: > E: Dynamic MMap ran out of room > E: Error occured while processing tqsllib0 (NewVersion1) > E: Problem with MergeList > E: The package lists or status file could not be parsed or opened. > > The package lists for testing and unstable (main) are quite large (> 2,5 MB) > compared to stable.
echo 'APT::Cache-Limit "25165824";' >> /etc/apt/apt.conf
Peace.
Karsten M. Self
Newsgroups: gmane.linux.debian.user Date: Wed, 08 Mar 2006 00:05:52 -0500
I've been following the "Debian Backports - Instructions" at http://www.backports.org/instructions.html to use backports so as to _deactivate_ all packages from backports.org by default. However, I noticed that at least one package is automatically updated from sarge to backport.
First of all, I've done all the settings required in the instruction:
$ grep backports /etc/apt/sources.list # backports deb http://www.backports.org/debian/ sarge-backports main
$ grep -1 backports /etc/apt/preferences Package: * Pin: release a=sarge-backports Pin-Priority: 200
This is the to-be-wrongly-updated package:
$ apt-cache policy hplip-ppds
hplip-ppds:
Installed: 0.9.3-3
Candidate: 0.9.7-3bpo1
Version Table:
0.9.7-3bpo1 0
200 http://www.backports.org sarge-backports/main Packages
*** 0.9.3-3 0
100 /var/lib/dpkg/status
It will be automatically updated from sarge to backport. Why? How can I prevent it?
thanks
FYI, Its "Reverse Depends" are:
hplip-base hplip hpijs
And none of the above depends will be updated:
$ apt-cache policy hplip-base
hplip-base:
Installed: 0.9.3-3
Candidate: 0.9.3-3
Version Table:
*** 0.9.3-3 0
100 /var/lib/dpkg/status
$ apt-cache policy hplip
hplip:
Installed: (none)
Candidate: 0.9.2-2
Version Table:
0.9.7-3bpo1 0
200 http://www.backports.org sarge-backports/main Packages
0.9.2-2 0
900 http://debian.yorku.ca sarge/main Packages
$ apt-cache policy hpijs
hpijs:
Installed: 2.1.2+0.9.2-2
Candidate: 2.1.2+0.9.2-2
Version Table:
2.1.7+0.9.7-3bpo1 0
200 http://www.backports.org sarge-backports/main Packages
*** 2.1.2+0.9.2-2 0
900 http://debian.yorku.ca sarge/main Packages 100
/var/lib/dpkg/status
thanks
> I've been following the "Debian Backports - Instructions" at > http://www.backports.org/instructions.html[] to use backports so as to > _deactivate_ all packages from backports.org by default.
No. You don't decativate them, you pin them to a lower priority than 500. 500 ist the default priority for packages available from some repository.
> This is the to-be-wrongly-updated package: > > $ apt-cache policy hplip-ppds > hplip-ppds: > Installed: 0.9.3-3 > Candidate: 0.9.7-3bpo1 > Version Table: > 0.9.7-3bpo1 0 > 200 http://www.backports.org[] sarge-backports/main Packages ^^^ > *** 0.9.3-3 0 > 100 /var/lib/dpkg/status ^^^ > > It will be automatically updated from sarge to backport. Why?
It is upgraded because the installed version has a lower priority (100<200). It has a lower priority because that version is not available in any archive. Probably because that version is outdated. By the way, where did you get it from? It is not part of stable. I recommend that you either upgrade or pin the installed version to > 200.
Andreas Janssen
>> It will be automatically updated from sarge to backport. Why? > > It is upgraded because the installed version has a lower priority > (100<200). It has a lower priority because that version is not available > in any archive. Probably because that version is outdated. By the way, > where did you get it from? It is not part of stable. [...]
Thanks for the explanation. I now feel relieved. FYI, my "stable" is downgraded from testing.
T
Newsgroups: gmane.linux.debian.user Date: Sun, 08 Jan 2006 13:14:44 -0500
I've been following the "Debian Backports - Instructions" at http://www.backports.org/instructions.html to use backports. However, it doesn't work for me:
I've done all the settings required in the instruction:
$ grep backports /etc/apt/sources.list # backports deb http://www.backports.org/debian/ sarge-backports main
$ grep -1 backports /etc/apt/preferences Package: * Pin: release a=sarge-backports Pin-Priority: 200
I want to install the backports' asciidoc.
$ apt-cache policy asciidoc asciidoc: Installed: (none) Candidate: 6.0.3-1 Version Table: 7.0.2-4 0 80 http://debian.yorku.ca testing/main Packages 40 http://debian.yorku.ca unstable/main Packages 7.0.2-3bpo1 0 200 http://www.backports.org sarge-backports/main Packages *** 6.0.3-1 0 1001 http://debian.yorku.ca sarge/main Packages 100 /var/lib/dpkg/status
However, when I issued the apt-get as instructed, only the mail sarge version is installed:
$ apt-get -t sarge-backports install asciidoc [...] The following NEW packages will be installed: asciidoc python2.4 [...] Setting up asciidoc (6.0.3-1) ...
$ apt-cache policy asciidoc asciidoc: Installed: 6.0.3-1 Candidate: 6.0.3-1 Version Table: 7.0.2-4 0 80 http://debian.yorku.ca testing/main Packages 40 http://debian.yorku.ca unstable/main Packages 7.0.2-3bpo1 0 200 http://www.backports.org sarge-backports/main Packages *** 6.0.3-1 0 1001 http://debian.yorku.ca sarge/main Packages 100 /var/lib/dpkg/status
Why is that?
How can I install backports packages properly? I want to, as recommended, to pick out single backports which fits my needs, and not to use all backports available.
T
-t, --target-release, --default-release,
This option controls the default input to the policy engine, it
creates a default pin at priority 990 using the specified re-
lease string.
However, my stable pin was 1001:
Package: * Pin: release a=stable Pin-Priority: 1001
Should be 900.
T
Best collection of info!
Newsgroups: gmane.linux.debian.user Date: Fri, 29 Jul 2005 20:59:33 -0700 (PDT)
> http://debianplanet.com/node.php?id=880[]
Oh my. There might be some good advice there, but I sure didn't see any.
> How do you guys downgrade? Are there sleek tools out there that can handle > this job better?
I've set /etc/apt/preferences to:
Package: * Pin: release a=stable Pin-Priority: 1001
and then did "apt-get dist-upgrade" to back out of a mess. Thought it worked rather well. Good luck!
James Vahn
To: debian-testing@lists.debian.org Date: Mon, 14 Jul 2003
Recently I downgraded two mixed Debian stable/testing systems:
I first tried it in a sandbox (vmware) to collect some experience with it. After some failures I finally succeeded and took notes about the steps which I think were most relevant. These notes follow at the end.
Then I did the same with a real system, which succeeded on the first try :-)
On both systems even libc6 was successfully downgraded from version 2.3.1 to version 2.2.5.
I used the information from the previous thread plus extensive Google'ing.
Of course systems differ a lot from each other. So you might experience other problems - I can't guarantee for anything!
If you have the chance, try it in a sandbox first!
As I said it worked for me.
Good luck, Rudolf
I actually first installed woody, then upgraded it to testing (via apt-get dist-upgrade) and then applied the following steps to downgrade it to woody again.
Search Google for: 'debian downgrading coreutils'
for: 'debian downgrading packages'
and for: 'apt pinning'
Create /etc/apt/preferences with the contents:
Package: * Pin: release a=stable Pin-Priority: 1001
Package: * Pin: release a=testing Pin-Priority: 60
Package: * Pin: release a=unstable Pin-Priority: 50
With /etc/apt/sources.list pointing to a stable and a testing distribution do:
apt-get update apt-get -s upgrade (just to check what would happen) apt-get upgrade
Most likely errors will occur like:
dpkg: error processing /var/cache/apt/archives/debianutils_1.16_i386.deb (--unpack): trying to overwrite `/bin/readlink', which is also in package coreutils
In this case the woody packages which contain the conflicting file should be installed with '—force-overwrite'. After this 'apt-get upgrade' will run further up to the next conflict. If in doubt about which packages to install manually consult Debians packages search page: http://www.debian.org/distrib/packages
Sometimes packages (in testing) depend on packages which do not exist in woody. This may be resolved by just removing the dependency packages. For example libpaperg_1.1.13 (testing) depends on libpaper1 and also libpaper-utils is in the way (both in testing): removing both by hand (—force-depends) allows libpaperg to be downgraded.
NOTE: coreutils is in testing only! To remove it four packages from woody must be installed first by hand: fileutils, shellutils, textutils and debianutils.
So continue the adventure similar to this:
dpkg -i --force-overwrite /var/cache/apt/archives/fileutils_4.1-10_i386.deb dpkg -i --force-overwrite /var/cache/apt/archives/shellutils_2.0.11-11_i386.deb dpkg -i --force-overwrite /var/cache/apt/archives/textutils_2.0-12_i386.deb dpkg -i --force-overwrite /var/cache/apt/archives/debianutils_1.16_i386.deb apt-get upgrade dpkg --force-depends -r dselect dpkg -i /var/cache/apt/archives/dpkg_1.9.21_i386.deb apt-get upgrade dpkg -i --force-overwrite /var/cache/apt/archives/sysvinit_2.84-2woody1_i386.deb dpkg --force-depends -r libpaper1 libpaper-utils apt-get -f upgrade dpkg -r tktable-dev apt-get upgrade
After installation of all packages 'apt-get upgrade' might still have problems configuring these packages because of dependency problems. It may help to remove one of the dependency packages explicitly and then reinstall it again (together with further dependency packages if needed), as with libgnomeprint-bin which could not be configured since it depended on the yet unconfigured package libgnomeprint-data:
dpkg --force-depends -r libgnomeprint-data apt-get install libgnomeprint-bin libgnomeprint-data
Now this did set up and configure both libgnomeprint-bin as well as libgnomeprint-data and all the remaining packages :-))))
However: Still libc6 Version 2.3.1 was installed (from testing)!
To downgrade libc6 to Version 2.2.5 (woody) force it with:
apt-get install libc6/stable
This will again remove and downgrade a lot of things, in particular now package coreutils will be removed which should not be problem since the woody equivalents (fileutils, shellutils, textutils and debianutils) are installed already. Nevertheless, if no important packages are to be removed (without being reinstalled or downgraded or being obsolete in woody, always check apt-get first with option -s) then affirm the execution of this command with 'Yes, do as I say!' as required by apt-get.
A few packages from testing still remained. Another
apt-get upgrade
reduced their number by another five. Just 14 packages from testing remained which seem to be not very essential:
dictionaries-common/testing uptodate 0.9.51 gcc-3.3-base/testing uptodate 1:3.3-2 gnome-desktop-data/testing uptodate 2.2.2-1 initscripts/testing uptodate 2.85-4.1 libgnomecanvas2-common/testing uptodate 2.2.1-1 libgnomeui-common/testing uptodate 2.2.0.1-2 libwnck-common/testing uptodate 2.2.2-1 python2.2-extclass/testing uptodate 1.2.0zope-2.5.1-1.2 python2.2-gadfly/testing uptodate 1.0.0-3 python2.2-htmlgen/testing uptodate 2.2.2-9 sysv-rc/testing uptodate 2.85-4.1 wenglish/testing uptodate 2.0-2.4 wngerman/testing uptodate 20030222-1 xprt-common/testing uptodate 0.0.8.cvs20030508-1
The rest of the system is now in woody again as confirmed by
apt-show-version
Finally, it seems to be a good idea to restart demons that depend on libc6 or just to reboot the machine (if possible) in order to make the demons depend on the new (old) libraries.
Rudolf Lohner
To: Debian Testing <debian-testing@lists.debian.org> Date: Sun, 07 Aug 2005
An IRC friend of mine downgraded three Etch boxes to Stable. I don't know if this is worth a bug report, but all three boxes errored out while downgrading dpkg.
The error message was:
dpkg: configuration error: unknown option log: Success E: Sub-process /usr/bin/dpkg returned an error code (2)
The way it we circumnavigated was by deleting /etc/dpkg/dpkg.cfg Afterward, the downgrades went smoothly.
Hope this helps someone,
Logan Tygart
> What are the dangers of using packages from both stable and testing?
You might want to look at http://backports.org, which contains many of the Sid packages backported for use with Woody. If that doesn't work, you might use apt's ability to download source packages and just recompile it yourself, to work with the Wooody libraries.
Carl Fink
using information from
http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html
section 6.14, you can quite easily recompile a Sid package using the Woody libraries to run under Woody (unless the program requires actual features not available in the older libs).
Carl Fink
> > section 6.14, you can quite easily recompile a Sid package using the Woody > > libraries to run under Woody (unless the program requires actual features > > not available in the older libs). > > Woody is 40,000 years old, and > developers don't like to be constrained to features that were only available > when mankind was first taming fire. Not when there's some new API call that
This is nice speculation I suppose, but in practice, I have not run into any packages that can't be compiled on woody, and only a few that required a whole lot of supporting packages to be backported. The folks over at backports.org certainly seem to have been able to backport a good many packages.
Mark
> One thing I *am* certain of, is that if you are running one release, > the risk increases proportionally with the number of additional > other-release packages that get sucked in with whatever you tried to > load from the other release. However, even so, it only takes *one* > infernal incompatibility to land you back at the command prompt with > X11 whining like a bad alternator bearing, or worse yet trying to > resurrect your system via CD-ROM...
Right. The usual sequence is this: someone is running stable; they fetch packages from testing or unstable; things work fine; they do it again; things work fine; they try to do it again, and run into a problem associated with a library incompatibility. The best way that this can play out is for the package management front end being used to tell them "if I install this, I'm going to have to remove these other packages too", so the user has a chance to either say "no no no" and not end up with a system missing software they need, or can choose to also install *those* packages from testing/unstable, or whatever. Of course, some users ignore such messages or just hit "y" to everything; but then, well, it's their fault when they need something that's no longer there.
But that's the best way it can play out. The worst way — which is thankfully uncommon, but can and does happen — is if Depends or Conflicts don't catch the problem. An example: package A in stable requires libfoo version 2.4 or greater; user installs package B, which requires libfoo version 3.1, and so that gets brought along, replacing v2.4; package A isn't marked for removal because 3.1 > 2.0; but software compiled against libfoo v2.4 chokes with libfoo v3.1, and so the binaries in package A are now broken). The package manager for libfoo can't set Conflicts: for *everything* compiled against earlier versions of libfoo because libfoo is just too commonly used. And if this happens with something like glibc, you're hosed.
Chris Metzler
> But that's the best way it can play out. The worst way -- which is > thankfully uncommon, but can and does happen -- is if Depends or > Conflicts don't catch the problem. An example: package A in stable
This scenario is always a bug in libfoo for breaking backwards compatability without changing its soname, and Debian has plenty of standard ways to deal with it that don't involve conflicting with lots of packages. If you see something like this, file a bug report.
viz
> This scenario is always a bug in libfoo for breaking backwards > compatability without changing its soname, and Debian has plenty of
Yeah. It still happens, though, viz. getting bit by #241360.
Chris Metzler
What it really comes down to is this:
Woody, is based on glibc6 2.2.5 (I think), where as currently Sarge and unstable have glibc6 2.3.2.ds1. Also the target compiler used for woody was version gcc 2.95.4. Testing/Unstable are currently targeting gcc 3.3.4.
These 2 very important reasons are the reason why mixing of Woody, Sarge and Sid is a bad idea. Now mixing of Sarge and Sid (right now) is a reasonable thing to do, but still not recommended. Reason being they are using very similar underlying libraries and compilers.
Woody, would more than likely implode upon itself, rendering it useful as a doorstop, after the catastrophic event happens. But, you can try it if you want. But, just make sure you are wearing the proscribed Lead lined Kevlar reinforced Nomex Fire suit, to weather the calls from your users.
greg
You are running Debian stable, because you prefer the stable Debian tree. It runs great, there is just one problem: the software is a little bit outdated compared to other distributions. That is where backports come in.
Backports are recompiled packages from testing (mostly) and unstable (in a few cases only, e.g. security updates), so they will run without new libraries (wherever it is possible) on a stable Debian distribution. I recommend you to pick out single backports which fits your needs, and not to use all backports available here.
Newsgroups: comp.os.linux.setup
> How can I upgrade Debrian from slint to potato? Please give me detailed > instruction. (My friend installed slint for me directly from internet.) > It is very scary to me to ugrade kernal and ugrade all installed > modules. thanks
There are instructions on debian's website on doing this. But, way to do it basically is to edit the /etc/apt/sources.list file as root and change reference to stable to frozen. Then run "apt-get update" to update the list of packages in the frozen tree. Then do "apt-get dist upgrade". You should probably subscribe to the debian user's mailing list and read up on any issues doing this (if some actually exist). I do my debian installs using the latest boot diskette and driver images and go from there.
Michael Perry
documented on: 2000.05.28
apt-get dist-upgrade instead?
documented on: 2001.03.24
Newsgroups: gmane.linux.debian.user Date: Fri, 16 Sep 2005 22:54:10 -0400
I am using sarge with this apt.conf:
APT::Default-Release "stable";
I have configured testing/unstable as additional sources in sources.list. My /etc/apt/preferences file looks like this:
Explanation: Keep unstable priority below installed Package: * Pin: release a=unstable Pin-Priority: 80
I came across bug 317914 which prevented me from unpacking Linus' kernel tree, and I thought it might be a good idea to add a preferences rule like this:
Package: cogito Pin: version 0.11.3* Pin-Priority: -10
To my understanding, "apt-get remove cogito; apt-get install cogito" with these settings should install version 0.12.1 from unstable instead of the broken testing version 0.11.3+20050610-1.
However, I am still getting 0.11.3. I have tried many other variations (assigning high priority to 0.12.x, changing the rule order, using Pin: release instead of Pin: version, …), but always with the same outcome. So I ended up doing simply "apt-get -t unstable install cogito", but I'm not satisfied with that solution. I'd like to understand why I couldn't get the preferences to work as desired.
The idea is "In general I give low priority to unstable; but I don't like version X of package Y in testing and would rather use the unstable version of that package". How can this be cast into /etc/apt/preferences syntax?
Martin
> The idea is "In general I give low priority to unstable; but I don't > like version X of package Y in testing and would rather use the unstable > version of that package". How can this be cast into /etc/apt/preferences > syntax?
apt-get -t unstable install cogito
Jiann-Ming Su