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'). Cheers, Phil _______________________________________________ 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
