[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Release Pinning Broken? (was Re: testing=sarge be careful with updates!)



On Fri, 26 Jul 2002 22:07:09 +0100
"Carlos Sousa" <csousa@tvtel.pt> wrote:

> On Fri, 26 Jul 2002 14:37:23 -0500 "Jamin W. Collins"
> <jcollins@asgardsrealm.net> wrote:
> 
> > Turns out the problem was with the order of my "unstable" and
> > "testing" entries.  Checking of all the packages to be updated
> > indicated that unstable and testing had the exact same versions.  It
> > appears that if two releases both have the desired version of a
> > package, the first entry listed in your sources.list file when you
> > last did and "apt-get update" is used, regardless of which release
> > it's for.  I've submitted bug #154408 on this.
> 
> If the version is the same, isn't the package *exactly* the same? Then
> why should it matter where it is downloaded from?

In most cases, yes the end result is absolutely the same.  However, the
information displayed to the user is _very_ misleading.  Such as what I
just experienced, "apt-get -u upgrade" happily listed the files and start
downloading everything from unstable.  I promptly interrupted it and
double-checked with "apt-get -s upgrade" and sure enough _every_ package
was being pulled from unstable.  I had to work a small script to pull
apt-cache information on each package before I found that they were the
same versions in testing and unstable for all packages.

> I've seen apt-get on my machine (tracking testing) sometimes fail the
> download of a package from testing, and then try to download it from
> unstable. Since it does this for packages that have the same version on
> both distributions, shouldn't this be regarded as a feature instead of a
> bug?

Possibly.  However, if I've pinned my system to testing, I don't feel that
the order of entries in my sources.list should appear to alter that
pinning.  In all cases, the pinned release should be the one used unless
specifically overridden.  

In your above example, were the testing and unstable entries for the same
server?  If not, the same redundancy feature can be attained by putting
multiple entries for a release in your sources.list.  And if they were for
the same server, I fail to see how one would succeed while the other
failed (unless we are looking at connectivity).

-- 
Jamin W. Collins


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



Reply to: