Bug#1025769: HTTP::Server::Simple vs. support for Unix domain sockets

[gregor herrmann]

On Thu, 08 Dec 2022 20:07:38 +0000, Ivan Shmakov wrote:

> 	Attempting to implement Unix domain socket support by
> 	subclassing HTTP::Server::Simple uncovered several issues
> 	with the latter, which I’m going to describe in this report.
> 	(Feel free to clone it and address them separately as you
> 	see fit.)

Thanks for your bug report.

I'm afraid to say that it mostly is not actionable from the Debian
packaging side. What you propose, in my understanding, are massive
changes to the code, and that's not what we are going to do on our
own in Debian, but something which needs to be discussed with
upstream and needs to happen there.

I can forward your ideas upstream but it might be easier if you do it
yourself as this will potentially require discussion:
https://github.com/bestpractical/http-server-simple
 
> 	Lastly, the package’s absolute dependency on libcgi-pm-perl
> 	is arguably at odds with Policy 7.2:
> 
>     http://debian.org//doc/debian-policy/ch-relationships.html
> 
>   Depends
> 
>     This declares an absolute dependency.  […]
> 
>     The Depends field should be used if the depended-on package
>     is required for the depending package to provide a significant
>     amount of functionality.
> 
> 	So far as I can tell, it’s perfectly possible to subclass
> 	and use HTTP::Server::Simple without libcgi-pm-perl, except
> 	perhaps with Net::Server (I’m not familiar with the latter
> 	and won’t claim understanding of what the run method does
> 	in the case net_server is supplied.)
> 
> 	For instance, the aforementioned test suite [2] completes
> 	successfully (aside of the SIGHUP issue above) even though
> 	I’ve circumvented the dependency by creating an otherwise
> 	empty Provides: libcgi-pm-perl package [3] with nope.sh [4]:
> 
> $ fakeroot -- nope  libcgi-pm-perl 
> 
> [3] http://am-1.org/~ivan/dist/no-libcgi-pm-perl_0.1_all.deb
> [4] http://am-1.org/~ivan/src/misc-utils-is-2020/nope.sh
> 
> 	The Recommends: relation seems like a better fit in this case:
> 
>    Recommends
> 
>      This declares a strong, but not absolute, dependency.
> 
>      The Recommends field should list packages that would be found
>      together with this one in all but unusual installations.

That's something relevant for packaging; but I'm not so sure about
your conclusion. After looking around a bit I think I can say that
lib/HTTP/Server/Simple/CGI.pm needs CGI.pm; libcgi-pm-perl needs to
be in Build-Depends-Indep, otherwise the tests fails (which was not
your point); moving libcgi-pm-perl from Depends to Recommends does
not break autopkgtests so it would be ok at first sight, the question
is if we want to ensure an always working HTTP::Server::Simple::CGI.
In the end I guess a Recommends would be arguable but it's not that
clear-cut IMO …


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: Digital Signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-perl-maintainers/attachments/20221209/4fa4c6c9/attachment.sig>