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

Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package



severity 119517 serious
reassign 119517 tech-ctte,pcmcia-cs
thanks

I am requesting a ruling from the Technical Committee on the meaning of
"dependency" as used in the Policy Manual.

My position is that shared library dependencies as determined by
dpkg-shlibdeps must always be delcared in a package's Pre-Depends or
Depends control data.

Mr. Mays's position is that shared library dependencies may be declared
as "dependency" relationship, which may mean one of two things:
  1) 'Depends', 'Pre-Depends', 'Recommends', 'Suggests', 'Enhances',
     'Conflicts', 'Provides' or 'Replaces'; or
  2) "Depends", "Recommends", "Suggests", "Enhances", or "Pre-Depends"
and that in any event, the selection of which of these relationships is
used should be a matter of the package maintainer's discretion.

I agree with Mr. Mays that the existing Policy Manual is insufficiently
clear on this issue.  Since Policy is now frozen for the woody release,
I am requesting an interpretive ruling from the Technical Committee that
will be binding for the woody release.  The Debian Policy group can, of
course, draft an amendment to the Manual that will be controlling for
subsequent releases.

As support for my position I offer the following arguments:

1) Failure of the runtime linker to load required shared libraries
results in the complete failure of the associated program to run.  No
friendly error message, no help text, zilch.  Traditionally, Debian
users have never had to deal with this sort of error except when there
were very serious problems (bugs) in a package (or when they are dealing
with non-Debian-packaged software).

2) If a part of a package depends on some shared libraries that are not
desirable in all scenarios, the part of the package that does so can and
should be split off.  Package fragmentation proliferation is not an
intrinsic evil; its costs must be weighed against the benefits.  I think
the benefits of dpkg-shlibdeps, when used as intended, are far too great
to ignore.

3) I suggest that it is unreasonable for "Conflicts", "Replaces",
"Provides", or "Enhances", as alternatives to "Depends",  to be
interpreted as a satisfactory usage of a "dependency" relationship when
delcaring an object's shared library dependency.  Perhaps this aspect of
his argument is facetious and he simply wants liberty to downgrade
shared library dependencies to "Recommnds" or "Suggests".

4) I know of no other package in Debian that behaves in this manner.
Every package I know of that has shared library dependencies declares
them as such (or doesn't declare them in the control data at all, which
I think Mr. Mays would agree is a bug).

I invite the Technical Committee to review the bug logs of #119517 for
further arguments for and against my request.

-- 
G. Branden Robinson                |    The errors of great men are
Debian GNU/Linux                   |    venerable because they are more
branden@debian.org                 |    fruitful than the truths of little
http://people.debian.org/~branden/ |    men.         -- Friedrich Nietzsche

Attachment: pgpQFf5Lv0NAb.pgp
Description: PGP signature


Reply to: