----- Original Message ----- > From: "James Hogarth" <james.hogarth@xxxxxxxxx> > To: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx> > Sent: Friday, April 6, 2018 12:09:10 PM > Subject: Re: Intent to orphan Python 2 > > 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. > AFAIK there is no guideline for making the packagers responsible for soft dependencies, or anything guiding how to check for those. If anything, the people who care about that should draft something to avoid those nuisances. Again if someone sees their package as leaves within the distribution, how could he be aware of anything requiring it outside the rpm level? At this point I don't think anyone would even think of the change process for packages that on the surface nothing depends on. > 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 > -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
