On Tue, 29.01.13 18:20, Miloslav Trmač (m...@volny.cz) wrote: > On Fri, Jan 25, 2013 at 4:25 PM, Marcela Mašláňová <mmasl...@redhat.com> > wrote: > > On 01/25/2013 12:17 AM, Adam Williamson wrote: > >> > >> On Thu, 2013-01-24 at 23:03 +0000, "Jóhann B. Guðmundsson" wrote: > >> > >>> It's best to rip the bandage of this in one release. > >>> > >>> The churn from this should have been more or less covered when we > >>> implement biosdevname so the fallout from this change should be minimal > >>> if any... > >> > >> > >> I see the 's' word in there ;) > >> > >> That's always the hope, and then we meet the cold reality, where someone > >> just patched 'em1' into everything and hoped that was good enough. But > >> sure, 'damn the torpedoes' is a viable approach too. I guess I was just > >> kind of hoping F19 would be a release without yet more churn in the core > >> system where we could try and stabilize things a bit. > >> > > I agree. The scope says no impact, but who knows how many packages depend on > > hardcoded names. > > It's not only "em1" mistakenly hard-coded in applications; it's user's > saved configuration, scripts etc., where often there is no practical > alternative to "hard-coding".
BTW: We have now updated the feature page to ask for removal of biosdevname from comps, as the discussions on fedora-devel kinda indicated that that'd be a good idea. We also added as optional part to the feature that we can disable the new rules on upgrade, so that the naming scheme stays unaltered on upgrades, even on systems where biosdevname was not installed before, and where fixed interface names were not in the network configuration files. We don't really like the implications of such a logic of disabling new features on upgrades, since that has the nasty effect that first installing version A of a package and then upgrading to B has a completely different effect than installing B right-away, but we don't really have any nice other idea either. We hence added this as optional part to the spec and would like to ask FESCO to decide on this at the same time as discussing the feature's overall merits. Or in other words, we'd like one of three answers from FESCO: a) feature declined, b) feature accepted but leave the new logic off on upgrades, c) feature accepted but enable it on upgrades too. I hope this makes sense, Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
