Secure testing team - Mar 2006 - [bug??] apt pinning on testing/etch secuirty archive

* Colin Ingram (synergymus@gmail.com) [050920 18:15]:
> As I said the opposite is true for the main repository (i.e. if I only 
> have release a= etch then security updates will be pinned 80 and main 
> will be pinned 500).  I don''t mind having both in my apt
preferences but
> I just though you would like to know about the inconsistency.
Thanks for your mail. The inconsistency should be fixed in something
like 20 minutes, but of course, that''s still not the final solution.


Cheers,
Andi

[please CC me Im not on the list]

I am unable to pin packages from the repository using the a=testing 
option, only a=etch works. (the opposite is the case for official 
repositories but thats a different email) I was unable to determine why 
since it seems your release files are in order.  screen shots below

When Pin: release a=testing is set...........

**********************************************************
colin@Alfalfa:~$ cat /etc/apt/preferences
Package: *
Pin: release a=sarge
Pin-Priority: 900

Package: *
Pin: release a=testing
Pin-Priority: 80

Package: *
Pin: release a=unstable
Pin-Priority: 50
colin@Alfalfa:~$
**********************************************************

sarge testing updates are not pinned 80.

**********************************************************
colin@Alfalfa:~$ sudo aptitude
f10: Menu  ?: Help  q: Quit  u: Update  g: Download/Install/Remove Pkgs
     Vi IMproved - enhanced vi editor
    --- vim-python (< 6.0)
    --- vim-rt
    --- vim-tcl (< 6.0)
    --- vim-tiny
    --- vim-tty (< 6.0)
  --\ Replaces
    --- vim-rt
    --- vim-tiny (< 6.0)
    --- vim-perl (< 6.0)
    --- vim-python (< 6.0)
    --- vim-tcl (< 6.0)
    --- vim-tty (< 6.0)
    --- vim-gtk (< 6.0)
    --- vim-lesstif (< 6.0)
    --- kvim (< 1:6.2.135+1)
  --- Package names provided by vim
  --- Packages which depend on vim
  --\ Versions
p  80   1:6.3-086+1
p  500  1:6.3-085+0.0etch1
i  500  1:6.3-071+1
     Vi IMproved - enhanced vi editor
**********************************************************

However if I add release a=etch....................

**********************************************************
colin@Alfalfa:~$ cat /etc/apt/preferences
Package: *
Pin: release a=sarge
Pin-Priority: 900

Package: *
Pin: release a=testing
Pin-Priority: 80

Package: *
Pin: release a=etch
Pin-Priority: 80

Package: *
Pin: release a=unstable
Pin-Priority: 50
**********************************************************

It works!!

**********************************************************
colin@Alfalfa:~$ sudo aptitude
f10: Menu  ?: Help  q: Quit  u: Update  g: Download/Install/Remove Pkgs
     Vi IMproved - enhanced vi editor
    --- vim-python (< 6.0)
    --- vim-rt
    --- vim-tcl (< 6.0)
    --- vim-tiny
    --- vim-tty (< 6.0)
  --\ Replaces
    --- vim-rt
    --- vim-tiny (< 6.0)
    --- vim-perl (< 6.0)
    --- vim-python (< 6.0)
    --- vim-tcl (< 6.0)
    --- vim-tty (< 6.0)
    --- vim-gtk (< 6.0)
    --- vim-lesstif (< 6.0)
    --- kvim (< 1:6.2.135+1)
  --- Package names provided by vim
  --- Packages which depend on vim
  --\ Versions
p  80   1:6.3-086+1
p  80   1:6.3-085+0.0etch1
i  500  1:6.3-071+1
     Vi IMproved - enhanced vi editor
**********************************************************



As I said the opposite is true for the main repository (i.e. if I only 
have release a= etch then security updates will be pinned 80 and main 
will be pinned 500).  I don''t mind having both in my apt preferences
but
I just though you would like to know about the inconsistency.

Andreas Barth wrote:
>* Colin Ingram (synergymus@gmail.com) [050920 18:15]:
>  
>
>>As I said the opposite is true for the main repository (i.e. if I only 
>>have release a= etch then security updates will be pinned 80 and main 
>>will be pinned 500).  I don''t mind having both in my apt
preferences but
>>I just though you would like to know about the inconsistency.
>>    
>>
>
>Thanks for your mail. The inconsistency should be fixed in something
>like 20 minutes,
>
great!   Thanks
> but of course, that''s still not the final solution.
>
>
>  
>
of course not...do you happen to know why the main debian archive is 
behaving strangely
>Cheers,
>Andi
>
>  
>