On Tue, Jan 07, 2020 at 10:16:05AM -0800, Kevin Fenzi wrote:
On Mon, Jan 06, 2020 at 06:02:12PM +0100, Phil Sutter wrote:
> I just noticed we didn't finish discussing the package rename proposal
> in related releng issue:
> On Wed, Oct 30, 2019 at 05:02:08PM -0400, Ben Cotton wrote:
> > To change the status quo, two measures are planned:
> > === Raise priority of nft-variants in <code>alternatives</code>
> > Currently, legacy variants are installed with priority 10 and nft
> > variants with priority 5. This must be changed as otherwise installing
> > <code>iptables-legacy</code> in a system with
> > <code>iptables-nft</code> installed would change the active
> > alternative (since they are in automatic mode by default).
> > On the other hand, existing systems using legacy variants should not
> > be changed by a system update. Therefore nft variants' priorities
> > should be chosen to match legacy ones.
> > === Rename <code>iptables</code> package ===
> > New name should be <code>iptables-legacy</code> which aligns with
> > ebtables and arptables and reflects upstream status. To resolve
> > dependencies, <code>Provides: iptables</code> statement will be
> > to <code>iptables-nft</code> package. This should automatically
> > the default variant to nft.
> My motivation for the rename is to abstract 'iptables' keyword other
> packages depend upon if they need (an implementation of) iptables.
> With matching Alternatives priorities, the first installed variant
> package wins and with given lexical ordering, if both legacy and nft
> variants are installed by default Alternatives will point at legacy.
> I want to avoid this (and also avoid legacy being installed if not used)
> by making sure a 'Requires: iptables' in any package may be satisfied by
> iptables-nft package as well. If adding 'Provides: iptables' to the
> latter is sufficient, that's fine with me.
That should work yeah, but also might need Obsoletes to handle upgrades?
(ie, remove the old 'iptables' package in favor of 'iptables-nft')
I don't want to move people from legacy iptables over to nft during
upgrade, that may cause unexpected side-effects.
So your question depends upon whether iptables package is renamed or
not. If not, nothing needs to be done to preserve upgrades. If it is,
I'll go with a compat subpackage just as I did for arptables and
My point in this thread is to clarify whether it is really possible to
establish my goals without renaming iptables package into
iptables-legacy and if so how many hacks are required.
> If my assumptions are correct, I assume there is still a
> iptables-nft' required in an always installed package like
> fedora-release, right? Also, which package would that be? I don't see
> fedora-release package being used for these things.
Not that I know of, Theres several places base sort of packages get
installed via: comps groups and kickstarts. It looks like iptables is in
the networkmanager-submodules comps group, and I don't see it in
kickstarts, but might be it's pulled via firewalld by anaconda or the
Yes, firewalld depends on 'iptables'. My big question is how to make
that dependency prefer iptables-nft (assuming it 'Provides: iptables').