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(a)in.waw.pl> 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).
* 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