On 6 April 2018 at 10:18, Petr Viktorin <pviktori@xxxxxxxxxx> wrote: > On 04/04/18 18:21, James Hogarth wrote: > [...] >> >> Can we please get some consistency here? >> >> I noted today that firewalld has dropped python2-firewall but of course >> ansible isn't switching to py3 for the controller (and therefore local) >> until F29 and not all python modules are py3 compatible yet... and of course >> we ship firewalld as our firewall in fedora. >> >> This means that in F28 you can't just `yum install ansible >> python-firewall` and do ansible localhost -m firewalld and have it work. >> >> Worse is if you bump into a module not ported yet and then you have a >> split of python versions and playbooks required. > > > Is there some list of packages Ansible depends on? > I'd can to add the list to portingdb, so we could warn people about the > implications of dropping subpackages. Currently we use RPM deps, so the > needs of Ansible clients are invisible. > It's not even as simple as that ... as Bill Nottingham mentioned the bigger problem is going to the be the thousands of libraries and plugins on eg ansible galaxy out there ... It's just going to be a huge (but required, just we need to be careful on communication so as not to tarnish our image ... especially with a core Red Hat technology like ansible) disruption. >> Naturally there's no technical reason to drop the library in F28 and >> there's no Change filed for it. > > > It's the maintainer's decision, as with any RPM. > Has anyone communicated to the firewalld maintainer that Ansible depends on > the package? Again, a maintainer can't very well notice a "soft dependency", > unless they use Ansible themselves. > Right ... but that's why we have the Change process - so stuff like this can get noticed in good time and those who are aware of soft dependencies can speak up. There's a good reason we have the change deadlines we do - and honestly I think dropping a subpackage (as opposed to retiring which is more visible) is sufficiently disruptive (and annoyingly invisible otherwise) that it should go through the Change process. It's also bigger than firewalld - that's just the one that bit me the other day when trying to do owncloud testing. Do note that, despite my dislike for dropping the subpackage without an announced Change, the biggest issue I see here is the sheer lack of communication with out userbase with what is going on. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
