Branden Robinson <[EMAIL PROTECTED]> wrote:
> I am requesting a ruling from the Technical Committee on the meaning
> of "dependency" as used in the Policy Manual.
I second this request.
> 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.
I support the alternative position that shared library dependencies
can be satisfied by any of the "Depends", "Recommends", "Suggests", or
"Pre-Depends" fields, according to the importance of the component of
the package that requires the shared library. I have never suggested
that "Conflicts", "Replaces", "Provides", or "Enhances" can or should be
alternatives to "Depends". I merely stated in an earlier message that
these are classified in the policy manual as a "dependency relationship"
between two packages
My argument is as follows:
Programs fail to run for all sorts of reasons and often do not give
friendly error messages, help text, etc. Problems are not only caused
by missing libraries, but also missing data or other executables that
the program expects to run. I fail to see the difference between a
program that is useless because a library is missing and a program that
is useless because it is a frontend for another program that is missing.
The program in question does not even need to be useless altogether;
many programs fail in unusual or confusing ways when the user activates
an obscure feature of the program that requires data or other programs
that are missing.
Therefore, for consistency sake, we should do one of two things:
1) Ensure that no program is installed in a state in which it can fail
due to missing components, whether they are shared libraries required
by the program, missing data, or other programs that are used by the
scripts or programs in the package. IMO, this leads to excessive
dependencies, since all packages will need to use "Depends" unless
the dependency is truly external and superficial. Many packages will
need to be split into tiny sub-packages to keep these dependencies
manageable.
2) Allow some components of a package to fail, as long as they are not
essential to the package's major functionality. With this approach, we
can group related components into one package and thereby simplify the
task of package selection, a process that becomes more complicated each
year. The purpose of each package is to provide a particular service or
function, not to provide a particular program.
In the second case, "Recommends" and "Suggests" become true
dependencies; they indicate other packages that are required to get
additional functionality from a particular package. With the first
approach (requiring "Depends" almost exclusively), these two fields
merely become opinions of the maintainer, pointers to packages that he
or she thinks are "neat" too.
Clearly, the Debian policy currently favors the second approach, as is
evident from the following paragraph from section 7.2 of the policy
manual (please forgive me for quoting this paragraph twice in this bug
report):
When selecting which level of dependency to use you should consider
how important the depended-on package is to the functionality of
the one declaring the dependency. Some packages are composed of
components of varying degrees of importance. Such a package should
list using `Depends' the package(s) which are required by the more
important components. The other components' requirements may be
mentioned as Suggestions or Recommendations, as appropriate to the
components' relative importance.
Of course, nowhere does the manual mention which level of dependency
should be used for shared libraries, but as I have argued above, there
should be no difference between a shared library and any other component
that a program would need to use.
I suspect that the paragraph from the policy manual above was written
fairly early in the life of the Debian project, when we were more
concerned with package fragmentation. (I distinctly recall Ian Jackson
arguing against the unnecessary splitting of packages in 1996.) I think
that excessive package fragmentation is a serious issue, which should
be addressed. I find it ridiculous that I must install one package
to get fetchmail and another package to configure it. In addition to
over-complicating the process of package selection, this splitting of
packages often causes annoying problems during upgrades. These problems
should not occur if everything is done correctly, but as I have noticed
in the past, this is rarely the case.
Additional comments were provided by Peter S Galbraith
<[EMAIL PROTECTED]>. He wrote:
> Ironically, this same utility was involved in a very similar situation
> in December 1998 when it was linked against non-free XForms, and the
> package had only a Suggests dependency on non-free/libforms. Some
> of us objected to a dependency on a non-free library for a package
> in main. Brian argued exactly the same point at the time, that the
> utility played only a small part in the package.
Has it been that long ago? Peter Galbraith is correct; I have used this
same argument before. Since that time, cardinfo no longer uses XForms.
> To the technical committee, if you rule that a package's minor
> binary's libraries need not be declared as a Depends (I hope not),
> then please address the same question with the added twist that the
> minor binary may need a dependency to non-free (which is usually not
> allowed for a package in main). I think this case should definately
> be forbidden as it's a slippery slope. One would then only need to
> package non-free stuff together with larger related free software in
> order to get into main something that would not be allowed by itself.
The last sentence is not entirely correct, or at least, is very
misleading. There is no way that non-free software could be included
in Debian's main distribution. This is prohibited by policy as it now
stands. The only possibility that can occur, which was addressed back
in 1998, is that free software (i.e., DFSG free software) that would
have been consigned to contrib could be included in main as a minor
component of a package. This software, however, cannot constitute a
significant portion of the package and cannot provide a significant
part of the functionality of the package. I don't see any problem with
this, however. If an additional free program is installed that requires
non-free stuff and it doesn't work, then where have we compromised our
values?
The opposite view, which has been advocated by RMS, is that free
software and packages of free software should make no mention of
non-free software whatsoever. IIRC, we have rejected this position in
the past, and still reject it today.
I have a couple of side notes that are not directly related to my
argument:
1) All dependencies should be declared at some level. That is, if the
dependencies are satisfied at all levels -- "Pre-Depends", "Depends",
"Recommends", and "Suggests" -- nothing should fail due to missing
components. My position is that if the user is willing to sacrifice
some components, however, he or she should be free to ignore some of
the lower level dependencies. If shared library dependencies (or other
similar dependencies on data or other programs) are not in the control
data at all, then this is a bug.
2) Use of dpkg-shlibdeps is not limited to dependencies at the "Depends"
level. It also works with "Recommends" and "Suggests". In fact, I use
it in the pcmcia-cs package to generate the "Suggests" dependency for
cardinfo.
I agree with Branden Robinson that this issue should be clarified. I
don't think that there is any one technically correct answer to this
question. Some resolutions are more consistent than others, however.
In the end, the answer depends on our philosophy of what constitutes a
package and what constitutes a dependency. I feel that my definitions
are closer to the original meanings of these two terms in the early
days of the Debian project, as reflected by the current wording of
the "Debian Policy Manual". My only hope is that, in the end, we are
consistent in the way in which we treat this problem.
Sincerely,
- Brian
--
Brian Mays
Debian Pcmcia-cs Package Maintainer
