On Sun, 2009-05-17 at 21:50 +0200, Aniruddha wrote:
> On Sun, May 17, 2009 at 4:38 PM, JoeHill <joeh...@teksavvy.com> wrote:
> > Aniruddha wrote:
> >
> >> I would like to install the latest version swfdec-mozilla (because it
> >> offers autoplay). I intent to track stable as closely as possible. As
> >> far I can tell there are four possibilities to achieve this:
> >>
> >> 1) Temporary enable testing/unstable repositories and install the program
> >> 2) Download *.deb from packages.debian org
> >> 3) Use apt-pinning
> >> 4) Compile from source, this requires option 1 to be enabled.
> >
> > I use apt-pinning and it works really well. I followed the Debian
> > apt-pinning
> > howto and now run a mix of Testing and Unstable.
> >
> > http://wiki.debian.org/AptPinning
> >
> > --
>
> Thanks for the tip. Are there any downsides to be expected from this
> method? e.g. accidentally pulling in dependencies for lots of packages
> turning my 'stable' into 'testing'. Is this a better option then
> temporary enabling testing/unstable repositories or downloading the
> debs from the debian.packages.org? And if so why? I'm really curious
> to find the best way to run stable while installing an occasional
> testing/unstable package. :)
There are always downsides. :-)
You won't "accidentally" pull lots of packages from testing unless you
aren't paying attention. That's important: pay attention. That said,
as long as you do pay attention and don't go blindly installing testing
or unstable packages, you should be fine.
I use a pretty conservative pinning, more conservative than what is
given on the wiki. Mine is taken from Martin Krafft's book "The Debian
System," recently recommended on this list:
mcu...@drifter:~$ cat /etc/apt/apt.conf
APT::Default-Release "stable";
APT::Cache-Limit 33554432;
mcu...@drifter:~$ cat /etc/apt/preferences
Package: *
Pin: release a=stable
Pin-Priority: 900
Package: *
Pin: release a=testing
Pin-Priority: 90
Package: *
Pin: release a=unstable
Pin-Priority: 80
With some packages, attempting to install them from testing or unstable
causes no issues whatsoever. For example, I recently installed zim from
testing (zim-0.28-1), rather than stable (zim-0.25.1), because the newer
version has several improvements. zim-0.28-1 only depends on packages
that are already in stable, so it didn't pull in any dependencies from
testing and didn't require any other upgrades. OTOH, look at what would
happen if I tried to upgrade transmission from stable to testing:
mcu...@drifter:~$ sudo aptitude install -s -t testing transmission
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
Reading task descriptions... Done
The following packages are BROKEN:
gtk2-engines-pixbuf libc6-i386 locales
The following NEW packages will be installed:
libgssapi-krb5-2{a} libk5crypto3{a} libkrb5-3{a} libkrb5support0{a}
The following packages will be upgraded:
libc6 libdbus-glib-1-2 libgcrypt11 libglib2.0-0 libgnutls26
libgpg-error0 libgtk2.0-0 libnotify1 libpcre3 libtasn1-3
libxrandr2 transmission transmission-cli transmission-common
transmission-gtk
The following packages are RECOMMENDED but will NOT be installed:
libglib2.0-data
15 packages upgraded, 4 newly installed, 0 to remove and 547 not
upgraded.
Need to get 11.3MB of archives. After unpacking 3309kB will be used.
The following packages have unmet dependencies:
libc6-i386: Depends: libc6 (= 2.7-18) but 2.9-4 is to be installed.
locales: Depends: glibc-2.7-1 which is a virtual package.
gtk2-engines-pixbuf: Depends: libgtk2.0-0 (= 2.12.12-1~lenny1) but
2.16.1-2 is to be installed.
The following actions will resolve these dependencies:
Upgrade the following packages:
gtk2-engines-pixbuf [2.12.12-1~lenny1 (stable, now) -> 2.16.1-2
(testing, unstable)]
libc6-i386 [2.7-18 (stable, now) -> 2.9-4 (testing)]
locales [2.7-18 (stable, now) -> 2.9-4 (testing)]
Score is 200
Accept this solution? [Y/n/q/?]
You can see that would be more disruptive. The good thing is aptitude
will tell you what it wants to do to satisfy your request, and you can
fiddle with it or reconsider whether your request is worth the potential
for trouble.
I suggest using the -s (--simulate) option anytime you are thinking
about installing a package from testing or unstable, just to give
yourself that much more forewarning about what might happen. If you do
end up taking the plunge with some packages that are really important to
you and wind up with substantial chunks of testing mixed in with your
stable system, then you probably also would want to be very careful
everytime you 'safe-upgrade,' maybe using the -s option there too.
Personally, I am being pretty conservative about the whole thing and
only installing a few packages here and there where the gain is
noticable and the pain is negligible.
Pinning gives you enough ammunition to shoot yourself in the foot (or
even shoot your whole leg off), but you won't do that if you're careful
with your trigger finger. If there's really so much from
testing/unstable that you want, you should probably consider abandoning
stable and upgrading your whole system.
For swfdec-mozilla:
mcu...@drifter:~$ sudo aptitude install -s -t testing swfdec-mozilla
[sudo] password for mcubed:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
Reading task descriptions... Done
The following NEW packages will be installed:
libswfdec-0.8-0{a} swfdec-mozilla
0 packages upgraded, 2 newly installed, 0 to remove and 562 not
upgraded.
Need to get 522kB of archives. After unpacking 1520kB will be used.
Do you want to continue? [Y/n/?]
Looks pretty painless to me. It doesn't seem to depend upon anything
that isn't already in Lenny.
--
Michael
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
