>>"Ian" == Ian Jackson <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> <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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]