On Wed, Aug 5, 2015 at 8:41 AM, Ryan S. Brown <[email protected]> wrote:
> 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 <[email protected]> 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 > [email protected] > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > As someone who is regularly using mock to build RPMs for various Fedora releases for $DAYJOB as well as for packages that I submit to Fedora Project, I would prefer if the ability to build RPMs for older releases is preserved (even EOL ones). As for the container things, it'd be interesting if mock could use DNF+nspawn for that work in the future, and if that means splitting out GPG keys and such into a package that both DNF and mock can use, that would be great. I personally don't think that having mock being able to build for older releases would encourage the view that Fedora supports older releases. -- 真実はいつも一つ！/ Always, there's only one truth!
-- devel mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
