--- Comment #5 from Laine Stump <> ---
> I recommend you reading <>.

That looks to me like it's talking about a different issue - it's pointing out
the problems of having one application that depends on a library that's
supplied with the package of another application (i.e. the other package has
both an application and a library). Did you maybe mean to point to a different

> As libvirt-tck uses Net::OpenSSH in a way that requires IO::Pty, why not add
> a dependency on perl(IO::Pty) to libvirt-tck, since that is where it is 
> needed?

That's my fallback plan if Net::OpenSSH doesn't get a Requires:, but doing that
leads to maintenance problems - what if the Net::OpenSSH  implementation is
changed to use something else instead of IO:Pty? (and that module is given the
same Suggests: treatment in the Net::OpenSSH specfile). The user updates their
packages, pulls in the new Net::OpenSSH, and suddenly libvirt-tck stops working
(and there is the less important issue that IO::Tty will still be installed
even though it is no longer used). Just as I dislike C .h files that require
their consumers to also include other .h files that end up only being used in
the first .h, I think packages should not need to list dependencies on other
packages that they don't directly reference.

There's likely several other perl modules that could arguably be made Suggests:
instead of Requires: in the Net::OpenSSH specfile because "module X is only
used if you use Y function in Net::OpenSSH", but where do you draw the line?
Maybe you should just make them all Suggests: and force consumer packages (and
user applications) to add their own Requires for (or manually install) every
individual subpackage. That seems very unfriendly though...

You are receiving this mail because:
You are on the CC list for the bug.
perl-devel mailing list --
To unsubscribe send an email to

Reply via email to