Re: Bug#641769: [apt] fetches InRelease file, problematic on several mirrors (aka "Packages Hash Sum mismatch")
[Adding the mirrors team in the loop]
Le 2011-09-16 05:22, David Kalnischkies a écrit :
Thanks for your detailed mail.
On Fri, Sep 16, 2011 at 01:21, Filipus Klutiero<firstname.lastname@example.org> wrote:
Since 0.8.11, APT fetches InRelease in preference to the classic Release
file. InRelease is an "Inline" signed Release file announced in
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).
FWIW, HTTP pipelining does not reduce the number of requests, it just
changes the way they're sent. What it could save is TCP segments.
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? ;)
Could you clarify what incoherence scenario InRelease avoids? It is true
that Release and Release.gpg need to be either versioned or updated
simultaneously, but this problem applies to all files used to fetch
indices, which are all updated during stage 1 (except for InRelease).
Therefore the duration of incoherence should be insignificant in
comparison to the problem with InRelease.
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.
I absolutely agree with that, and would encourage anyone to get involved
in the mirrors team and get mirrors up-to-date. However, until someone
finds the time to do that, APT needs to take the situation into account.
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.
I'm not sure what problem we would be "hiding" here. Mirrors using
ftpsync versions that don't handle InRelease correctly is only a problem
insofar as APT uses InRelease with problematic ftpsync versions...
As I said, this problem does not just affect unstable, it already
affects testing and would probably affect stable, and eventually all
releases if nothing is done.
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
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.
As I said after, I'm not convinced that #626026 is worth the effort - if
I had the time, I would work on the general issue with the mirrors team,
I certainly won't be sending a patch for #626026.
Just implementing that enhancement wouldn't really hide problems - users
would still hit the bug, until they would configure APT to workaround it.
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.
Uh, Debian is an actual GNU/Linux distribution, not just a draft. If
offering a patch is not enough, feel free to leave code to ease having
InRelease support, perhaps a compile-time option. Or even to make the
APT source support InRelease by default and to only disable it in
Debian. All I'm saying is that something needs to be done for Debian proper.
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…
This is an interesting idea. I agree this isn't strictly an APT bug. The
system has never been designed reliably, and only worked reasonably
thanks to cooperation between APT, mirrors and the archive. If you think
this should be addressed elsewhere, feel free to reassign to the general
pseudo-package or to the archive maintenance team, marking the report as
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.
Right, but as I tried to say, I don't think even the mirrors team has an
overview on the status at this time. I've looked at mirrors web pages
quite a bit and saw nothing. I asked #debian-mirrors "is there a list of
mirrors that shows each mirror's ftpsync version?" 2 days ago and
received no answer so far.
Preventing this kind of issue is not the sole responsibility of the