Re: Bug#641769: [apt] fetches InRelease file, problematic on several mirrors (aka "Packages Hash Sum mismatch")

[Filipus Klutiero <chealer@gmail.com>]

[Adding the mirrors team in the loop]

Hi David,

Le 2011-09-16 05:22, David Kalnischkies a écrit :
> 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).

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
> > 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.

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 
affecting 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.

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 
mirrors team.