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

Re: Current shared library dispute


>>"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

	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

 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?


- -- 
 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
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by: Debian GNU/Linux -> Emacs -> Gnus -> Mailcrypt


Reply to: