Bug 1629814 - libdnet: Remove (sub)packages from Fedora 30+: python2-libdnet
Summary: libdnet: Remove (sub)packages from Fedora 30+: python2-libdnet
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: libdnet
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Oliver Falk
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: PY2REMOVAL
TreeView+ depends on / blocked
 
Reported: 2018-09-17 13:06 UTC by Miro Hrončok
Modified: 2018-10-09 10:51 UTC (History)
11 users (show)

Fixed In Version: libdnet-1.12-28.fc30
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-09 10:51:11 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Miro Hrončok 2018-09-17 13:06:48 UTC
In line with the Mass Python 2 Package Removal [0], the following (sub)packages of libdnet were marked for removal:

 * python2-libdnet

According to our query, those (sub)packages only provide a Python 2 importable module. If this is not true, please tell us why, so we can fix our query.

Please remove them from your package.

As said in the change document, if there is no objection in a week, we will remove the package(s) as soon as we get to it. This change might not match your packaging style, so we'd prefer if you did the change. If you need more time, please let us know here.

We hope this doesn't come to you as a surprise. If you want to know our motivation for this, please read the change document [0].

[0] https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal

Comment 1 Oliver Falk 2018-10-02 16:04:46 UTC
I've removed python subpackage now (commit 1226bedad08709fa8ee233d0e8d7cc865f259cea). However, the code is pretty unmaintained since years and I wonder if we should reach out to the developer and ask him if he is still interested in this project or not.
Completely removing the libdnet package seems to be a bad idea at the moment, since we still have some other packages depending on it (repoquery in F27):

# dnf repoquery --whatrequires libdnet
ArpON-0:3.0-2.fc25
daq-modules-0:2.0.6-4.fc27
firewalk-0:5.0-18.fc27
labrea-0:2.5.1-15.fc26
open-vm-tools-0:10.1.10-3.fc27   <--- side question: why do i see this duplicate!?
open-vm-tools-0:10.3.0-4.fc27
open-vm-tools-test-0:10.3.0-4.fc27
scanssh-0:2.1.1-12.fc27
tcpreplay-0:4.2.5-3.fc27
unicornscan-0:0.4.7-15.fc27

I'm the maintainer of scanssh (that's the reason why I brought in libdnet back in 2005) and I'd not like to see this package being removed. Opinions?

Comment 2 Miro Hrončok 2018-10-02 19:59:34 UTC
> side question: why do i see this duplicate!?

It may be that one version is int he repo and one installed on your machine. or one in the fedora repo and one in updates. It just happens sometimes.

> Completely removing the libdnet package seems to be a bad idea at the moment

I'd reach to the maintainers of dependent packages and ask them. I lack any knowledge about libdnet (except for the request made trough this bugzilla).

I'm keeping this open so you can keep it as a reminder that you want to do something, but feel free to close at any time (my request was fulfilled, thanks).

Comment 3 Zbigniew Jędrzejewski-Szmek 2018-10-02 20:48:43 UTC
> side question: why do i see this duplicate!?

Here I see:
$ dnf repoquery --whatrequires libdnet|grep open-vm-too
open-vm-tools-0:10.3.0-4.fc29.i686
open-vm-tools-0:10.3.0-4.fc29.x86_64
open-vm-tools-test-0:10.3.0-4.fc29.x86_64

which means that open-vm-tools is blessed to be multilib (however that is officially called).

You seem to be using an older dnf, so that's probably why the format string is a bit different.

Comment 4 Oliver Falk 2018-10-03 12:46:35 UTC
Zbigniew, I'm running this on some VM which is still i686. And open-vm-tools 0.10.1 and 0.10.3 are both i686. But never mind, I know this happens...

I'll reach out to the other maintainers and ask them if/how we can go further and also to the upstream maintainer of libdnet if he abandoned the project...

Comment 5 Oliver Falk 2018-10-09 10:51:11 UTC
I've rebuilt libdnet with the currently much newer version from boundary (see github) and this builds fine with Python 3 now. Therefore I'll close this BZ now.


Note You need to log in before you can comment on or make changes to this bug.