gwhois depends on inetd

Dropped the Depends on both of the mentioned packages to Recommends, though is this the ideal solution? The package itself looks to be just a single combined client-server script, so I guess it can't really be separated.

Hi,

If the package no longer depends on an inetd then it can't rely on "update-inetd"
being available, so the postinst and prerm need to be updated to check for the
presence of update-inetd before calling it.

The package ships a debconf question asking whether to use an inetd. Is that
no sufficient? I guess not wanting to have an inetd installed is a reasonable
desire.

The debconf question should perhaps not default to "true" if there is no inetd
available, what do you think?

Thanks,

James

Hi,

even if you choose to not use the inetd, the package dependency enforces
an inetd to be installed. The dependency should be turned into a
recommendation.

regards
Hadmut

I was originally going to have debconf set a question default depending on whether or not an inetd was installed, but ran across a roadblock: the package can't tell if an inetd will be installed if it is being installed the same time as gwhois, since the config is ran before unpacking.

So, the debconf question remains as it was and still defaults to true, but with an added note that it needs an inetd to run as a server. The prerm and postinst scripts then check for the existence of /usr/sbin/inetd and act accordingly on the debconf value.

Is this a feasible solution?

> Is this a feasible solution?

Yup, seems OK.

regards
Hadmut

Hi,

Thanks for working on this.

I would much rather the Debian maintainer got a chance to look at this first.
Not least because your changes change the debconf template, and so getting
translations of that would be important. Would you file a bug against the Debian
package and describe your proposed changes to see if they respond.

Thanks,

James

James:

Thanks for the response. I'll file a Debian bug when I return from classes today to see what the maintainer thinks. However, in the meantime, would it be suitable to go with the most recent solution but without the template/translation changes, and then merge/sync the Debian version when it is updated? I think the debconf dialog (and the Recommends field) should appropriately hint that an inetd server needs to be installed, even though the extra string would be helpful.

Thanks for your help,
Jacob

On Tue, 2009-01-27 at 13:27 +0000, Jacob Peddicord wrote:
> James:
>
> Thanks for the response. I'll file a Debian bug when I return from
> classes today to see what the maintainer thinks. However, in the
> meantime, would it be suitable to go with the most recent solution but
> without the template/translation changes, and then merge/sync the Debian
> version when it is updated? I think the debconf dialog (and the
> Recommends field) should appropriately hint that an inetd server needs
> to be installed, even though the extra string would be helpful.

Well, I haven't fully reviewed the package yet to make sure that not
depending on an inetd is both reasonable and worthwhile, though the
debconf question certainly indicates that it is.

Also, I'm not sure how to handle the case when someone installs
without recommends, and answers yes to the question (which defaults to
yes, and they may well not have seen it). You are entirely correct that
it's not possible to detect this case in the config script, but I
wonder if there is a better way to handle it.

Thanks for working on this, it's not the easiest change to make,
otherwise I may well have uploaded it already. I'm keen to get
any feedback from the Debian maintainer, as they know the package
better.

Thanks,

James

Wouldn't a better solution be splintting the debconf, and all the inetd/xinetd bits to a seperate, possibly virtual package, and making that depend on super server?

That way people who want the server part get the client as well, but those who just want the client don't get the server?

Copying the comment i made to the bug report in debian:

The problem here is that the package automatically configures inetd when the user enable the
"server". Splitting into two different packages as suggested in the bug
thread on ubuntu makes no sense because the server part actually is none,
so the package would be empty which the exception of the postinst etc.
scripts.

Currently i have no idea how to handle this. I already considered to
implement the "server" without using inetd, but i'm not sure if this really
a good idea. gwhois would need a complete rewrite anyway though.

This got fixed in Debian, and the Ubuntu package is in sync. So I'm fixing it as "Fix released". Please re-open if you feel otherwise.