Re: Current shared library dispute
-----BEGIN PGP SIGNED MESSAGE-----
>>"Brian" == Brian Mays <email@example.com> writes:
>>"Manoj" == Manoj Srivastava <firstname.lastname@example.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
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.
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
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
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
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 <email@example.com> <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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by: Debian GNU/Linux -> Emacs -> Gnus -> Mailcrypt
-----END PGP SIGNATURE-----