Bug#641769: [apt] fetches InRelease file, problematic on several mirrors (aka "Packages Hash Sum mismatch")
Hi Filipus,
Thanks for your detailed mail.
On Fri, Sep 16, 2011 at 01:21, Filipus Klutiero <chealer@gmail.com> wrote:
> Since 0.8.11, APT fetches InRelease in preference to the classic Release
> file. InRelease is an "Inline" signed Release file announced in
> http://lists.debian.org/debian-devel-announce/2009/11/msg00001.html
> If I understand correctly, the only real noteworthy advantage of InRelease
> at the moment is that it avoids one HTTP request, improving performance.
It avoids more than just a http request - in fact it doesn't save a request at
all as multiple requests are combined by APT (http request pipelining).
If you decrease the time between the dinstall (or equivalent) runs to lets say
an hour as e.g. ubuntu does you get far more likely in situations in which
Release and Release.gpg doesn't belong together. Thats specifically one of
the reasons ftpmasters implemented it in 2009.
So, you are currently experience mirror-problems because we want to
protect you from mirror problems in the future. Crazy, heh? ;)
> retry indices updates about 1 day on 2. If everyone was using my mirror,
> that would have affected quite a lot of people.
[…]
> The problem with ftpsync is that the mirrors team doesn't seem to have much
> infrastructure to ensure it stays up-to-date. There is no package for
[…]
> be considered outdated. Overall, coordination between the mirrors team and
> mirror administrators appears to have little structure.
I have never seen this in real life. Maybe i am just incredible lucky, but
more like is that others have hit this problem and contacted mirror-admins
before i could. Sure, we could disable InRelease now or add an option or
whatever, but this means that again nobody will notice that mirror-admins
are using outdated scripts for updating. It's not unlikely that in future we
will have other files we need to take care of in one or the other way, so we
are better getting all this in order now before we have to later.
So with disabling InRelease we would just hide the underlying problem,
this can't be a solution, especially not that early in the releasecycle.
After all, we are talking about unstable-only here.
> The other solution, which I came to the conclusion should be implemented
> after polling #debian-mirrors, is to make APT avoid InRelease. Josh Triplett
> filed an RFE asking APT to provide an option to disable use of InRelease
> files: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626026
Feel free to implement it and provide a patch.
I personally don't believe in hiding problems, so i will not invest time into
that (even if the patch shouldn't be damn hard), but commiting a patch
with good documentation would be in order, i guess.
> The question is then when should InRelease use be re-enabled [by default]? I
> suggest to file an issue report against the mirrors pseudo-package to track
> this issue, and to request the mirrors team to close it when they'll
> consider that APT can safely use InRelease.
Given that InRelease is used by others already without any problems it would
be a shame to revert them just because a single archive and (parts of) its
mirror network has problems with them -
even if this single archive is debian itself.
If the mirror-team really recommends to revert it - and i haven't heard that
so far - it might be a better idea to remove the file from the debian archive
instead for the foreseeable future as it is not really a bug in APT…
But either way this is something the mirror-team has to decide and ask for
as they have the overview over the status. I can only speak for the very
limited world of de and de2 and these seem to behave fine.
I don't know what happens on the rest of the world (mirror-wise) and
i assume every other "normal" user has a similar limited view.
Best regards
David Kalnischkies
Reply to: