On Thu, Jan 9, 2020 at 5:15 AM Phil Sutter <psutter@xxxxxxxxxx> wrote: > > Hi Kevin, > > 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[1]: > > > > > > 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 added > > > > to <code>iptables-nft</code> package. This should automatically change > > > > 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 > ebtables earlier. > > 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 'Suggests: > > > 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 > > like? > > Yes, firewalld depends on 'iptables'. My big question is how to make > that dependency prefer iptables-nft (assuming it 'Provides: iptables'). > Requires: iptables Suggests: iptables-nft -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
