Re: Current shared library dispute
-----BEGIN PGP SIGNED MESSAGE-----
>>"Anthony" == Anthony Towns <aj@azure.humbug.org.au> writes:
Anthony> On Mon, Dec 03, 2001 at 07:46:48PM -0600, Manoj Srivastava wrote:
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.
Anthony> The distinction between these to things is significant, however.
This is a matter of opinion.
Anthony> debconf: dpkg-preconfigure only works if apt-utils is installed;
Anthony> that it doesn't work doesn't cause
Anthony> significant problems, though, and there's a
Anthony> nice error message
There is a nice error message when a library an binary depends on
can't be found; however, that is generally not a reason for doing
away with all dependencies. So, whether one can easily figure out
what the bug in a package is does not make it any less a bug.
In this particular case, I would suggest that the
dpkg-preconfigure is indeed at fault, since it the documentation
never mentions that one requires apt-utils; and it just fails to
work.. Either depend on apt-utils, split out dpkg-reconfigure to a
separate package, or move it to apt-utils.
Thanks for pointing out the bug.
Anthony> ifupdown: DHCP stanzas only work if a DHCP client is
Anthony> installed,
Anthony> IPX stanzas only work if ipx is installed, some of the
Anthony> IPv6 stuff only works if iproute is installed and none
Anthony> of these things are depended upon
__> man ifupdown
No manual entry for ifupdown
Hmm. I see, I need man ifup. As far as I can see it, here the
special case stanzas enhance the operation of ifupdown; which can
handle stuff built into the base system, but needs additional
packages to handle special case networking.
Anthony> Other scenarios are possible too, which can't be rectified by just
Anthony> installing other packages: kernels and modules that only work with
Anthony> particular hardware, programs that only work with particular kernels
Anthony> (and thus require at least a reboot as well as a dpkg -i).
That again is out of scope if this discussion, which is
scoped to deal with inter package dependencies. You may wish to
pursue that discussion on the debian-devel list, or elsewhewre, and
not on the debian-ctte mailing list.
>> 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).
Anthony> Which seems to say that you see a difference between, say:
Anthony> $ /sbin/cardctl # works
Anthony> $ cardinfo # fails because of missing library
Anthony> and
Anthony> $ /usr/bin/pcmcia-cs-helper cardctl # works
Anthony> $ /usr/bin/pcmcia-cs-helper cardinfo # fails because
Anthony> # of missing library
Anthony> (The former fails because not all bins in the PATH "work"; the latter
Anthony> succeeds because all the bins in the PATH "work", although
Anthony> some non-core functionality isn't available)
I guess I am not being pedantic enough. I am not interested in
crafting legalese designed to stand up to purely lawyerly nit
picking, and you need take my recommendation with a modicum of common
sense. Obviously, a shell wrapper around binaries shipped, though
exploiting a loop hole in the letter of my opinion, does circumvent
the spirit of it.
If you indeed are seeking clarification; I think I would like
to see required libs for binaries (with or without wrappers) be
addressed by the dependencies.
Anthony> Personally, I don't think that's a particularly worthwhile
Anthony> distinction to make.
You are indeed entitled to an opinion.
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.
Anthony> Well, your expectations are wrong. As they are for dpkg-preconfigure.
Wrong? These are subjective matters, and the opinion of the
tech ctte has been asked for .The opinion of this member of the
committee still stands, as a matter of record.
I still think that going fuzzy on dependencies might be
expedient, but certainly not to be recommended technically, and does
not really contribute to the quality of the distribution. Since when
has expediency trumped rigor?
>> I am sorry. We do not need to delve into documentation to
>> determine dependency requirements;
Anthony> And, you need to delve into the documentation to work out
Anthony> you need to say `apt-get install ipx dhcp-client' if you want to have
Anthony> iface eth0 inet dhcp
Anthony> iface eth0 ipx static
Anthony> blah
Anthony> in /etc/network/interfaces, too.
Added functionality. Enhancements. Base functionality
works. Binary script not useless with dependencies satisfied. Works
for the common case out of the box. You are repeating yourself here.
Anthony> That doesn't seem particularly legitimate. You're claiming
Anthony> that its an unreasonable burden to expect users to be able
Anthony> to cope with "error while loading shared libraries: foo:
Anthony> cannot open shared object file: No such file or directory"
Anthony> when they're already expected to cope with similar sorts of
Anthony> error messages for hardware or kernel problems (which could
Anthony> equally be detected at installation rather than use).
Slackware users don't need no steeenkeeeng dependency
relations already. We are not slackware. And when we get reliable,
and accesible hardware information, and can create dependency
relations the packaging system can handle, we shall no doubt enhance
technical policy to deal with that.
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.
Anthony> Certainly. Likewise cardinfo and dpkg-preconfigure are also
Anthony> add ons which provides aesthetic improvements, as long as
Anthony> you add on other packages.
I am repeating this one last time: a script or a binary
shipped with the package should not be useless if all the depends are
satisfied.
in the make-kpkg case, some of the options are not available;
in the case of the other two, the binaries/scripts do not work at
all.
Anthony> Their only difference is that they're installed into a file of their
Anthony> own in the PATH.
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
Anthony> How about a binary not in the PATH?
As long as it is not directly used by the end user, it is not
part of the contract of the package, or part of the exposed
UI. Again, this is not a hard rule writ in stone and meant to serve
as a loop hole; I expect Debian maintainers to use a modicum of
common sense when it comes to application of general policy.
Examples are not part of the contracted interface the package publishes.
Anthony> The only real benefit over the current situation that I can see seems
Anthony> to be that it lets us be righteously pedantic about policy.
Your opinion. I am not particularly interested in this line of argument.
Anthony> Does dpkg-preconfigure offend your sensibilities when apt-utils isn't
Anthony> installed?
Yes.
manoj
- --
progasm: the feeling you get when your code works the first time
uunet!sugar!karl (hm) Keeping 255 messages and deleting
158. karll@sco.com (wk) re
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by: Debian GNU/Linux -> Emacs -> Gnus -> Mailcrypt
iD8DBQE8DIIvIbrau78kQkwRAd3NAKC50r65umqcRmfMCkGyVVPerB+HsACg3GNg
0E+g+6d1KZxP5lich3l2n1Y=
=FFRx
-----END PGP SIGNATURE-----
Reply to: