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:
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,
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.
"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
* As till pointed out, mock seems to already carry these keys, so
coordination here seems like a good idea no matter what we do. ;)
issue I see is that mock seems to be always trailing with
the updates. Mock in F22 now has
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
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.