Hi Filipus, Thanks for your detailed mail.
On Fri, Sep 16, 2011 at 01:21, Filipus Klutiero <chea...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
