[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Current shared library dispute


>>"Brian" == Brian Mays <brian@debian.org> writes:

>>"Manoj" == Manoj Srivastava <srivasta@debian.org> writes:
 Manoj> Seems to me that the underlying principle here (the
 Manoj> cause majuer for having dependencies at all) is whether
 Manoj> the program works as advertised on installation.  If I
 Manoj> have installed the package, with the dependencies (but not
 Manoj> necessarily the recommended packages), I would expect to
 Manoj> have all the functionality mentioned in the documentation
 Manoj> (except functionality explicitly designated optional). ...
 Manoj> Presence of a binary in a standard path, and functionality
 Manoj> mentioned in documentation shipped in the package, implies a
 Manoj> minimal contract with the user that the binary shall work as
 Manoj> advertised, or that there is a bug in the package.

 Brian> First, I believe that you are confusing two separate issues here.
 Brian> One is the advertised functionality of the package, the other is the
 Brian> advertised functionality of an individual program.

	I may be deliberately blurring the restriction as being
 insignificant, but I most certainly am not confused about the distinction.

 Brian> In the specific case being discussed, the advertised functionality
 Brian> of the package is to provide PCMCIA support.  If you have installed
 Brian> the pcmcia-cs package with the dependencies (without any recommended
 Brian> packages) satisfied, you indeed have this functionality, assuming that
 Brian> the system has been properly configured.

	I would also say that if a package ships with a binary, that
 binary should work (I would accept the fact that any non-core
 functionality of the binary may require suggested packages to be
 enabled; I see that as fitting the enhanced by the presence of this
 other package aspect of the recommends/suggests relationships).

 Brian> If we are discussing the functionality of the individual
 Brian> components of the package, then to be fair, we should restrict
 Brian> our discussion to the advertised functionality of these
 Brian> components alone.  For example, the advertised functionality
 Brian> of the cardinfo program is indicated in the title of its man
 Brian> page (the documentation shipped in the package):

 Brian>     $ apropos cardinfo
 Brian>     cardinfo (1) - PCMCIA card monitor and control utility for X

	And, if the package this binary lives in is installed, with
 the dependencies satisfied, I expect it to work on the machine, with
 no additional quibbles.

 Brian> This clearly indicates that cardinfo is an X program, thereby also
 Brian> implying that the system must also support X.  The program works as
 Brian> advertised.

	I am sorry. We do not need to delve into documentation to
 determine dependency requirements; we have other mechanisms in place
 for that.  The mere presence of the binary in a package implies that 

 Manoj> Having an executable that does not work at all,
 Manoj> despite all the dependencies being satisfied, would be very
 Manoj> surprising, and, in my opinion, a bug in the package.

 Manoj> Hence, if one ships a binary, all the shared libraries
 Manoj> required to have it run _must_ be present in the packages
 Manoj> pulled in by the dependencies.

 Brian> I don't know exactly what you mean by "does not work at all."
 Brian> Certainly, I can run xterm on a serial terminal or the linux console,
 Brian> and it will not work at all.  It doesn't even tell me directly what
 Brian> is missing.  (I must know what the program means by "display".)  An
 Brian> executable that fails because of an unsatisfied library could perhaps
 Brian> fail with a more informative message; however, this has been discussed
 Brian> already, and I don't believe it means that all shared libraries packages
 Brian> *must* be listed in the Depends field of the control file.

	This is stretching the circumstances. We are specifically
 talking here of interpackage relationships, not whether the user has
 chosen to take an Axe to the CRT, the power cable, or the
 keyboard. Please restrict yourself to the package
 relationships. Missing hardware is beyond the scope of this

 Manoj> I also posit that this situation is general, and applies
 Manoj> to perl scripts requiring libraries, python scripts, and even
 Manoj> shell scripts sourcing shell snippets, Makefiles including
 Manoj> other Makefile snippets, or any such dependency encountered
 Manoj> by a user attempting to run a executable, script, or other
 Manoj> advertised functionality provided by the package.

 Brian> Your point is valid, and indeed, I argued this exact position
 Brian> in my response to the bug report that initiated this
 Brian> discussion.  Logically, it makes perfect sense.

	Thank you.

 Brian> I, however, used this position as part of a counter-argument
 Brian> against the report, since it can easily be taken too far.

	Anything can be taken too far. However, one assumes a modicum
 of common sense to also be applied; and in this case, I refuse to
 move from a position that you yourself acknowledge to be logical on
 the grounds that in some cases, some one may take it too far. When
 that happens, please bring it to the notice of the project, and we
 shall dismiss any positions that have obviously gone too far.

 Brian> For example, by strictly applying your assertion above, I
 Brian> could argue that the kernel-sources packages should depend on
 Brian> xlibs (in addition to other packages), since the configuration
 Brian> command "make xconfig" (or "make-kpkg --config x") is an
 Brian> "advertised functionality provided by the package" (i.e., it
 Brian> is clearly mentioned in /usr/share/doc/<package>/README, which
 Brian> I would take as the second most important place, behind the
 Brian> package's description, to find a list of the package's
 Brian> functionalities).

	If you read the readme, it is advertised as an value add on,
 which provides aesthetic improvements, as long as you add on other
 packages. It certainly is not the only way to arrive at the end goal
 (a configured package), and is never mentioned as a functionality you
 may expect without additional requirements being met.

	And certainly no binary/script si shipped that does not work
 at all with the dependency requirements being met.

 You may configure the kernel to your setup by typing "make config"
 and following instructions, but you could get ncursesX.X-dev and
 tkX.X-dev and try "make menuconfig" for a jazzier, and easier to use
 interface. Also, please read the detailed documentation in the file

 If you wish to use this package to create a custom Linux kernel, then
 it is suggested that you investigate the package kernel-package,
 which has been designed to ease the task of creating kernel image


	Indeeed, kernel-source packages are careful not to make any
 statements about suitability for any other purpose than studying the
 sources. Indeed, and I quote:


Before you go any further, please allow me to point out that you need to
have a few other packages installed before you can compile your own kernels
(it is difficult to compile anything without a compiler ;-). 

Firstly, you will need gcc, the libc development package (libc5-dev or
libc6-dev at the time of writing), and, on Intel platforms, bin86. [If
you use the menuconfig target of make, you will need ncursesX.X-dev,
and make xconfig also requires tkX.X-dev, and other packages these
depend on]

The packages suggested are:
devel:        gcc, libc5-dev/libc6-dev, binutils, make, and, for intel
              x86 platforms, bin86 (non-Intel platforms don't need
interpreters: awk, which is contained in either the mawk or gawk packages
base:         gzip, shellutils, and grep.

Some of these packages are marked essential, and hence are going to be
present on your machine already. Others you have to check and install.


	The kernel source packages are a special case, but I have been
 careful to set them up to not advertize functionality not provided by
 the dependencies.  You would have been better pointing to
 kernel-package, which still merely recommends libc-dev, gcc,
 debianutils, make.  Arguably, the make-kpkg script actually works,
 but fails to produce a kernel image without the recommended
 packages. (The core functionality sucks, but is massively enhanced
 were you to install recommended packages).

	 I would not oppose a finding that kernel-package, too, is at
  fault here. 

 Brian> (I realize that you only mention the requirement of included Makefile
 Brian> snippets as a strict requirement.  If make fails, however, does it
 Brian> really make a difference whether it failed because an included file was
 Brian> missing or a necessary program was missing?)

	I am unsure that I understand your argument here. Could you elaborate?

 Brian> Your assertion does not take into account whether the
 Brian> functionality of this subset of the package is essential to
 Brian> the functionality provided by the package as a whole.

      My stance is that that is immaterial. If a binary is shipped
 with the package, it ought to work with the dependencies 

 Brian> If you argue that "make xconfig" is clearly designated as part
 Brian> of the optional functionality of the package, then I should be
 Brian> able to make the same claim for the cardinfo binary.  The
 Brian> package description might need to be modified a bit to clarify
 Brian> this point.

	Sorry. The fact that a non functioning binary is present is,
 in my view, a real and significant difference.

- -- 
 I'm RELIGIOUS!!  I love a man with a HAIRPIECE!!  Equip me with
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
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by: Debian GNU/Linux -> Emacs -> Gnus -> Mailcrypt


Reply to: