Haines Brown wrote:
> I still get "Unable to locate package chromium". It seems that when I
> did update/dist-upgrade after modifying sources.list to accommodate
> daedulus I did not get the no InRelease file error. The chimaera
> previously installed on this disk did not have chromium installed.
What does this say for you?
apt-cache policy chromium
It should say something similar to this.
root@clash:~# apt-cache policy chromium
chromium:
Installed: (none)
Candidate: 100.0.4896.127-1
Version table:
100.0.4896.88-1 500
500 http://deb.debian.org/debian daedalus/main amd64 Packages
If it does not then investigate why not.
It's just possible that having changed suites that apt is waiting for
an acknowledgment. This was added in some recent year.
--allow-releaseinfo-change
Allow the update command to continue downloading data from a
repository which changed its information of the release contained
in the repository indicating e.g a new major release. APT will fail
at the update command for such repositories until the change is
confirmed to ensure the user is prepared for the change. See also
apt-secure(8) for details on the concept and configuration.
Specialist options (--allow-releaseinfo-change-field) exist to
allow changes only for certain fields like origin, label, codename,
suite, version and defaultpin. See also apt_preferences(5).
Configuration Item: Acquire::AllowReleaseInfoChange.
To acknowledge the change do this as root.
apt-get update --allow-releaseinfo-change
apt-get update
Then follow the acknowledgment by another update. It's confusing but
as far as I can see from documentation and experimentation it needs
both of those. The first to acknowledge and the second to actually do
the update of the new Packages indexes. After that everything should
be available.
> I tried $ sudo apt-get --allowUnauthenticated install chromium, but
> this command was unable to locate chromium.
>
> I did not create a file /etc/apt/apt.conf/d/99myown with line
>
> APT::Get::AllowUnauthenticated "true";
>
> because very insecure. In any case I'm not sure it would work
The main useful purpose of --allow-unauthenticated is for *older*
releases in the archive that have expired keys. Because those are
archived they are not getting signed with updated keys. The original
signatures are still as indicative as before but now they have expired.
--allow-unauthenticated
Ignore if packages can't be authenticated and don't prompt about
it. This can be useful while working with local repositories, but
is a huge security risk if data authenticity isn't ensured in
another way by the user itself. The usage of the Trusted option for
sources.list(5) entries should usually be preferred over this
global override. Configuration Item:
APT::Get::AllowUnauthenticated.
Daedalus is currently active and there should be no need to use the
--allow-unauthenticated option.
It's also useful for unsigned local repositories and other uses too.
Not to give the idea that it isn't ever useful. But it worries me to
be used for Daedalus on the currently active reposities.
Bob