I disagree that including the keys for EOL'd releases counts asOn 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).
"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
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 devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
