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

Bug#597301: apt should not ignore NotAutomatic and ButAutomaticUpgrades if key is missing



Package: apt

Hi,

thanks a lot for implementing and ButAutomaticUpgrades!

I just played a bit with Release files to be able to test this feature,
it seems to work :)


There is one somehow related bug, which does not seem to be a problem
for backports.debian.org but a possible one for other repositories that
use a different key: apt ignores NotAutomatic and ButAutomaticUpgrades
from Release files (or rather the whole Release file) if it is signed
but the key is missing.

I'm not sure what the reason to ignore signed Release files with missing
key is, but at least NotAutomatic and ButAutomaticUpgrades from such
repositories should not be ignored.

To reproduce it in a more clean environment I removed all keys in
a fresh sid debootstrap, ran apt-get update and then added experimental
to the sources.list.  After an other apt-get update, apt-cache policy
abook printed the following:

  abook:
    Installed: (none)
    Candidate: 0.6.0~pre2-1
    Version table:
       0.6.0~pre2-1 0
          500 http://ftp.us.debian.org/debian/ experimental/main i386 Packages
       0.5.6-7 0
          500 http://ftp.us.debian.org/debian/ sid/main i386 Packages


I found also an other minor issue, if the Release file in the archive
changes but the Package file does not, it is necessary to remove
/var/cache/apt/*bin to let apt use the new setting.  This does not look
like a bug that is worth the effort to fix it since such situations
normally should not happen.  Though, one way to fix it, would be to stat
the Release files and compare the mtime of these files every time the
cache is used.


* David Kalnischkies [2010-09-14 19:03 +0200]:
> NotAutomatic needs to be present for compatibility anyway so the
> sense is not completely lost and a bit easier to understand then
> NotAutomaticButUpgrades -- but a better name can always be suggest
> (until it is too late of course), maybe someone wants to do at least this…

| NotAutomatic: yes
| ButAutomaticUpgrades: yes

This looks good when both are read together :)

Maybe OnlyAutomaticUpgrades or AutomaticUpgradesOnly would be better
names if it is not read together.  I think "Only" or "But" is important
because normal repositories also do automatic upgrades, so just
"AutomaticUpgrades: yes" would be confusing.

Anyway, the field name of this option does not seem to be that
important, as long as it is not changed after Squeeze has been released.


Regards
Carsten



Reply to: