On 08/01/2015 03:25 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Aug 01, 2015 at 10:40:45AM -0600, Kevin Fenzi wrote: >> On Fri, 17 Jul 2015 17:28:48 +0000 >> Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: >> >>> [In light of https://bugzilla.redhat.com/show_bug.cgi?id=1241383] >>> >>> 'dnf install --installroot=... --releasever=XX dnf' can be used to >>> bootstrap a Fedora chroot. The only snag is that --nogpg is often >>> recommended, because fedora-repos only provides the GPG keys for the >>> current and next release. >>> >>> It would be convenient (and safe!) to provide keys for past and >>> future releases, so such bootstrapping can be done without either >>> importing the keys manually and/or using --nogpg. >>> >>> I thought I'd ask here first: is there a strong reason *not* to >>> include those keys? >> >> So, I missed this thread, but saw it from the bug filed: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1246701 >> >> Several things here: >> >> * If we ship gpg keys for old eol Fedora releases, aren't we >> encouraging people to setup things we no longer support? > I never asked for keys from EOL releases. I think keys should > be removed after EOL. > >> * If we only ship supported releases in each fedora-repos package, it >> means more churn for that package for everyone as when a release goes >> EOL we would need to push a new update that removes the old EOL key. > Is "everyone" the users or they maintainers of fedora-repos.rpm? > The "churn" is really tiny: the package is small, and this happens > only twice a year, so I dont' think users will notice or care. As for > the maintainers: I know it is a bit of extra work. I'm trying to ask > nicely :) > >> * As till pointed out, mock seems to already carry these keys, so some >> coordination here seems like a good idea no matter what we do. ;) > Yeah. One issue I see is that mock seems to be always trailing with > the updates. Mock in F22 now has > /etc/pki/mock/RPM-GPG-KEY-fedora-19-primary > /etc/pki/mock/RPM-GPG-KEY-fedora-19-secondary > /etc/pki/mock/RPM-GPG-KEY-fedora-20-primary > /etc/pki/mock/RPM-GPG-KEY-fedora-20-secondary > /etc/pki/mock/RPM-GPG-KEY-fedora-21-primary > /etc/pki/mock/RPM-GPG-KEY-fedora-21-secondary > /etc/pki/mock/RPM-GPG-KEY-fedora-22-primary > /etc/pki/mock/RPM-GPG-KEY-fedora-22-secondary > The version in updates-testing removes keys for F19 and F20, > and adds keys for F23. It has chroot definitions to match those keys. > *If* mock was relying on fedora-repos to carry they keys, it would > be possible to have chroots without a matching key. I don't > know if that would be good (EOL chroots stop working as expected) or > bad (EOL chroots stop working unexpectedly). I disagree that including the keys for EOL'd releases counts as "encouraging" people to use old stuff. If someone has a reason to be building RPMs for something way-old, I think it'd be nice for us to keep those GPG keys available for them. Speaking only for myself, whenever I have to build something for a very old box, the last thing I want is mock giving me grief about not having a GPG key that old. >> * Can you describe the use case here a bit more? Why wouldn't you use >> mock (which has the keys already) to make a chroot? > I want to use dnf to create containers, e.g. for running with > systemd-nspawn. Sometimes for installation of Fedora on a disk > to bootstrap a new machine. In either way, it is a one-time > operation where the result is permanent. > > mock is about repeatedly creating chroots tailored for rpm building... > The underlying installation mechanism is pretty much the same, > but that's about it. > > Zbyszek > -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
