Re: Intent to orphan Python 2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux