Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package
Branden Robinson writes ("Bug#119517: pcmcia-cs: cardinfo binary needs to move into a s eparate package"):
...
> I think both should be forbidden.
>
> ELF objects, minor or major, must declare shared library dependencies
> as Depends.
This is a silly position.
For example, here is are two alternative suggestions which would make
it reasonable (in the instant case) for cardinfo to link against
libraries only mentioned via Suggest or otherwise:
(a) The pcmcia-cs maintainer could choose to make `cardinfo' be a
script which checked whether the appropriate libraries were present
and otherwise produced a more helpful error message.
(b) The libc maintainer could choose to `improve' the error message
from ld.so so that it was considered suitable for the kinds of users
Branden presumably wants to avoid seeing it.
Both of these would clearly be feature requests. Furthermore, it
seems to me to be very much a matter of opinion whether these are
better than the current situation.
So in summary, I don't consider the current behaviour (fail with an
appropriate error message, which standard mechanisms would allow the
user to diagnose) sufficiently bad to say it's a bug.
(I assume that the situation is documented in the manpage for
cardinfo or some other appropriate places; if not, I assume the
pcmcia-cs maintainer will agree that it should be.)
Having read what the policy manual has to say, I agree that it's
slightly unclear if you're a bit stubborn. The section on the
meanings of dependency fields (7.2) is clear, IMO. But, in 9.3, it
says:
You will need to place a ${shlib:Depends} variable in the Depends
field in the control file for this to work.
If you have an axe to grind, you might interpret this to mean that
only a Depends field was allowed. I think this is a disingenuous
reading, but if people complain perhaps we should fix it. I suggest
we add a footnote, as follows:
You will need to place a ${shlib:Depends} variable in the Depends
field[##] in the control file for this to work.
[##] Or another appropriate dependency field, such as Recommends or
Suggests (see section 7.2).
(Of course the Technical Committee does not interpret the policy
manual, though we may specify its contents. Our judgements about
packages stand on their own.)
> ELF objects, minor or major, that link against non-free shared libraries
> must not go into main.
I don't think this is a technical issue. Whether we allow a Suggests
dependency out of main into non-free (or indeed any other kind of
reference intended to an administrator or user that non-free software
should be used) is a political question, which the Technical Committee
is not supposed to decide. I think the Project Leadership should
decide (subject to the oversight in the Constitution).
If the political decision is that references from main to non-free are
prohibited, then clearly a even a Suggests, or an unannounced
dependency, is inappropriate. Then the program should be in contrib.
What do other members of the Committee think ?
Ian.
Reply to: