Re: Technical Committee: decision on #119517?
>>"Ian" == Ian Jackson <ian@davenant.greenend.org.uk> writes:
Ian> Manoj Srivastava writes ("Re: Technical Committee: decision on #119517?"):
>> From reviewing the bug report, Ian Jackson sided with the
>> maintainer, with the opinion that not all binaries shipped with a
>> package need work when the dependencies are satisfied. Dale Scheetz,
>> Jason Gunthorpe, and I disagreed.
Ian> So, the current situation is as follows:
Ian> The package pcmcia-cs contains, amongst many other more important
Ian> things, a binary `cardinfo' which is an X program. It declares a
Ian> Suggests dependency on the X libraries.
Ian> The complaint is that this is wrong, and instead either pcmcia-cs
Ian> should Depend on xlib6g, or the X11 cardinfo program should be split
Ian> into a separate package. (There was also a fudge suggested, making
Ian> cardinfo a wrapper script to do something completely different, to
Ian> avoid using X, if xlib6g wasn't present.)
No. The suggestion, which you apprently did not follow, was to
provide core functionality of the program regardless of X, and added
functionality when X libs are present. In other words, the program,
the interface the user sees, actually does something.
Ian> As I understand it, the supposed principle which is being applied is
Ian> that it is unacceptable to have a binary in the package which depends
Ian> on libraries not mentioned in Depends, and that Recommends or Suggests
Ian> are not sufficient.
Nope. The objection is that a package presents an interface to
a user to added functionality, and binaries provided by a package are
the user interface most commonly seen by users towards that. Any
binary that fails is a bug in the package. Mitigating factors are
that a package may not be properly installed.
If I install a package properly, all dependencies satisfied,
all binaries work. Added recommended or suggested packages may
enhance functionality; but the b i n a r i e s M U S T w o r k.
Ian> 1. I think the current situation is fine. The other suggested
Ian> approaches to this issue have much worse effects than a slightly ugly
Ian> but perfectly informative error message.
I disagree strongly. This is a quality of implementation
issue. When I go on a machine, fire off a binary, and it faults, I
know the machine is broken.
Ian> Forcing the user to always install the X libraries with pcmcia-cs is
Ian> clearly unacceptable.
Ok.
Ian> Splitting the package up is gross overkill - the general cost of an
Ian> additional package to maintain, update, select, install, cope with
Ian> dependencies of, find, etc. etc. is considerable.
Really? I would rahtter add one more package to the nearly 10k
list than have broken systems all over the place.
Suggests does nto mean install suggested packages, or else
some binaries are just going to fail. Why the hell have a dependency
system with differeing levels at all, if you can no longer be sure
what one needs install in order to have binaries work?
Ian> Note that a person who forgets to install X when they wanted
Ian> cardinfo is even more likely to fail to spot the proposed
Ian> pcmcia-cs-cardinfo package; when they want to run cardinfo
Ian> because they heard about it from a colleage running some other
Ian> distribution, we serve them better by giving them the ld.so
Ian> error message than by making the file vanish !
Debian is already different enough that this is not a major
issue. The added package can be mentioned in the cardinfo
description, be recommended by the non X package, and be mentioned in
the documentation.
Ian> The only remaining approach suggested was to make cardinfo a wrapper
Ian> script which would either invoke the real X cardinfo program, or do
Ian> some kind of text-mode alternative if X wasn't available; I think this
Ian> is a hideous idea.
Far better than giving the impramatur of approval to having
randomly broken binaries unless you install every single darned
suggests dependecy package.
Ian> It is a pointless piece of programming, since it adds no new
Ian> functionality or ease of use (people who wanted the text UI will
Ian> invoke it directly).
yeah, it just makes sure that programs in debian kinda work,
rather than be discovered randomly after the install phase is over,
and one no longer has access to the install system. That is
ridiculous.
Ian> In fact, it seems to me that much of the aim of the complainants
Ian> here is to suppress the error message. I think this is a
You just don't get it. The aim of the complainnat is that when
one installs a package, one should be sure that the programs included
actually work.
Ian> Is this suggested principle, that binaries' dependencies on shared
Ian> libraries should always be declared as Depends:
The binaries should actually work when the package install
went fine.
Ian> There are many programs which just fail if you request the use of a
Ian> feature which needs an unsatisfied Recommends or Suggests. Some
Ian> examples:
Ian> * cron Recommends mail-transport-agent. But, cron is supposed to be
Ian> able to send mail and can't if you don't install
Ian> mail-transport-agent; the messages that cron would send effectively
Ian> get lost. However, you can still use cron in this configuration -
Ian> you just have to make explicit arrangements in your crontab entries
Ian> for capturing the output.
Ian> * fvwm Suggests m4. If you install it without m4 but ask for to
Ian> m4-preprocess your file, it will fail.
Ian> * minicom Suggests lrzsz. If you install it without, you can still
Ian> use it, but the rz/sz file transfer commands will not work.
Ian> * groff contains gxditview, which is an X program, but only Suggests
Ian> xlib6g.
Every single one of these packages the program can be
used. They are, (voila!) working. Add suggested packages, they can do
extra things, work better. But the base code does more than produce
error messages.
manoj
--
If you break a cup or plate, it will not be the one that was already
chipped or cracked. -- Denys Parsons
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-ctte-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: