Hi Cyril, Le 29/06/2019 à 16:20, Cyril Brulebois a écrit : >> If installing gnupg is what it takes to fix the bug, IMHO it should be >> done; anyway, with this patch, it would be installed only if a local >> repository with a GnuPG key is used at all. > > Well, I proposed doing so a while ago but that didn't happen. Looking at > the current gnupg package, it's not about installing just a single, > extra package: > > Depends: dirmngr (<< 2.2.13-2.1~), dirmngr (>= 2.2.13-2), gnupg-l10n (= > 2.2.13-2), gnupg-utils (<< 2.2.13-2.1~), gnupg-utils (>= 2.2.13-2), gpg (<< > 2.2.13-2.1~), gpg (>= 2.2.13-2), gpg-agent (<< 2.2.13-2.1~), gpg-agent (>= > 2.2.13-2), gpg-wks-client (<< 2.2.13-2.1~), gpg-wks-client (>= 2.2.13-2), > gpg-wks-server (<< 2.2.13-2.1~), gpg-wks-server (>= 2.2.13-2), gpgsm (<< > 2.2.13-2.1~), gpgsm (>= 2.2.13-2), gpgv (<< 2.2.13-2.1~), gpgv (>= 2.2.13-2)
I agree with you on the fact that the dependencies are quite heavy. I noticed that, but I didn't realize that the GnuPG keys could just be dropped in /etc/apt/trusted.gpg.d/ (more on that later). Good point. > I'm also not sure what part of dirmngr and/or gpg-agent are going to > stay around running, after calling “apt-key add” with gnupg installed. I didn't even know that could be a problem. Again, good point. > Testing that was conceivable a couple of weeks/months back; a few days > before an archive freeze, not so much. Well, the patch in [1] (which is far better than mine, by the way) dates from April 9th, 2018, so it was not for a lack of trying... :) > Plus, we've got a MR against apt-setup now, see #851774. It's also come > late and nobody reviewed it yet. Plus, the other, serious bug report was > marked as buster-ignore by a release team member, so there's no *need* > to fix this before buster. What exactly does "MR" mean ? I googled but I didn't find anything. > All in all, it looks like we're instead going to consider the MR at the > beginning of the bullseye release cycle, and backport the fix to buster > if it proves to be working fine. That's where I disagree. More precisely, I don't understand how the current situation (which is that generators/60local crashes systematically, unless in the very rare case that an unsigned repository is configured, **and** debian-installer/allow_unauthenticated is set) can be preferable to merging the patch in [1] before release. (There was also a merge request based on this patch [2] which didn't receive any answer) Please enlighten me (I'm not being ironic here, this is a legitimate question, I really don't understand how releasing Buster with a partly broken apt-setup is preferable to merging a patch which is admittedly not tested by a lot of people, but is so simple that it's very unlikely to fail, especially when 60local nearly **always** fail without a fix). Personally, I don't mind, since my PXE server has a complex preseed system with preseed file snippets, scripts and hooks everywhere, so adding a hook to replace 60local for Buster was very easy; but I'm thinking of people who use a single preseed file, they will have a really bad surprise when Buster is released. If you don't change your mind, please at least agree that this bug (and its possible workarounds) must absolutely be documented with big fat warnings in the preseed documentation [3]. I have to say that I **really** miss the times when a new Debian release was ready "when it's ready"... :( [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851774#61 [2] https://salsa.debian.org/installer-team/apt-setup/merge_requests/1 [3] https://www.debian.org/releases/stable/amd64/apb.html.en Regards, -- Raphaël Halimi
signature.asc
Description: OpenPGP digital signature
