Bug 1331825

(In reply to Roy Sigurd Karlsbakk from comment #0)
> There really isn't a good reason
> to keep this out, since IPv6 is getting rather common these days

IPv6 support in this package is optional and it's documented.
By requiring it you force it onto users who might not want it, for whatever reasons.  Note that behavior would also be different from upstream.

The dependency could be expressed with `Recommends', however, I'm not sure whether this is supported in EPEL7.

IPv6 support by default is required by the packaging guidelines:
https://fedoraproject.org/wiki/Packaging:Guidelines#Networking_Support

There is nothing in EPEL-specific guidelines to the contrary, so the above applies for EPEL as well. Please add the missing Requires.

I see no reason for holding back on this one. IPv6 is essensial these days.

If there's no reply within a week, I will fix this myself (as provenpackager).

Created attachment 1286376 [details]
Patch backporting the change from master.

Nothing has changed about my previous comment. IPv6 support in this package is optional.  If you want support for it, you can always install IO::Socket::INET6.  Optionally.

Adding a hard dependency on it forces it onto people who don't need it and differs from upstream behavior.

If you believe Net::Server users shouldn't have a choice in this matter, the best way would be discussing it with upstream.  The package could then follow upstream decision.

I'm not against IPv6, far from it.  Just stating the facts.

I'm also against hard coding the dependency. If there is something to be changed in this package regardgin IPv6 support, then it is replacing IO::Socket::INET and IO::Socket::INET6 with IO::Socket::IP. But that's definitely a job for the upstream.

(In reply to Petr Šabata from comment #6)
> Nothing has changed about my previous comment. IPv6 support in this package
> is optional.  If you want support for it, you can always install
> IO::Socket::INET6.  Optionally.
> 
> Adding a hard dependency on it forces it onto people who don't need it and
> differs from upstream behavior.

That's a decision that Fedora (and EPEL) made already:
https://fedoraproject.org/wiki/Packaging:Guidelines#Networking_Support
[...]
If an application contains native and stable support for both IPv4 and IPv6, and support for IPv6 does not negatively affect IPv4 then both MUST be enabled in the Fedora package.

IPv6 is NOT optional unless it breaks IPv4 usage. Please either point to a bug report saying that installing IO::Socket::INET6 breaks IPv4 connectivity in Net::Server or add the dependency as required.

> If you believe Net::Server users shouldn't have a choice in this matter, the
> best way would be discussing it with upstream.  The package could then
> follow upstream decision.

If you believe Net::Server users should have a choice in this matter then the best way would be to propose making IPv6 optional in the Fedora (or EPEL) Packaging Guidelines. The package could then follow the Packaging Guidelines.

> I'm not against IPv6, far from it.  Just stating the facts.

As am I.

(In reply to Dominik 'Rathann' Mierzejewski from comment #8)
> (In reply to Petr Šabata from comment #6)
> > Nothing has changed about my previous comment. IPv6 support in this package
> > is optional.  If you want support for it, you can always install
> > IO::Socket::INET6.  Optionally.
> > 
> > Adding a hard dependency on it forces it onto people who don't need it and
> > differs from upstream behavior.
> 
> That's a decision that Fedora (and EPEL) made already:
> https://fedoraproject.org/wiki/Packaging:Guidelines#Networking_Support
> [...]
> If an application contains native and stable support for both IPv4 and IPv6,
> and support for IPv6 does not negatively affect IPv4 then both MUST be
> enabled in the Fedora package.

Okay, I admit I didn't know about or remember this rule -- there's nothing to discuss then.  Although you might want to change the wording as it explicitly says "in the Fedora package".

(In reply to Petr Šabata from comment #9)
> (In reply to Dominik 'Rathann' Mierzejewski from comment #8)
[...]
> > That's a decision that Fedora (and EPEL) made already:
> > https://fedoraproject.org/wiki/Packaging:Guidelines#Networking_Support
> > [...]
> > If an application contains native and stable support for both IPv4 and IPv6,
> > and support for IPv6 does not negatively affect IPv4 then both MUST be
> > enabled in the Fedora package.
> 
> Okay, I admit I didn't know about or remember this rule -- there's nothing
> to discuss then.

Thank you.

> Although you might want to change the wording as it explicitly says "in the
> Fedora package".

https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_for_EPEL

Packaging for EPEL

For the most part, these guidelines and the application-specific guidelines below cover packaging for both Fedora and EPEL. However, there are necessarily some differences. When packaging for EPEL, please also consult the EPEL packaging guidelines for additional information.

Module is build with "BuildRequires:  perl(IO::Socket::INET6)", i am closing this ticket.

(In reply to Michal Josef Spacek from comment #11)
> Module is build with "BuildRequires:  perl(IO::Socket::INET6)", i am closing
> this ticket.

This ticket is about adding a run-time dependency, not a build-time dependency. The Fedora package has had "Requires: perl(IO::Socket::INET6)" since 2016 but it has not been added to the epel7 package.

@paul Ah, sorry.

I created PR for it: https://src.fedoraproject.org/rpms/perl-Net-Server/pull-request/1

FEDORA-EPEL-2022-22044ac958 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-22044ac958

FEDORA-EPEL-2022-22044ac958 has been pushed to the Fedora EPEL 7 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-22044ac958

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-EPEL-2022-22044ac958 has been pushed to the Fedora EPEL 7 stable repository.
If problem still persists, please make note of it in this bug report.