Re: Bug#30739: When a tiny part of a package uses non-free libraries
Remco Blaakmeer <remco-blaakmeer@quicknet.nl> wrote:
> This is a very wrong viewpoint of the use of the three dependency
> levels, and it is definitely not how they are used in Debian.
Although I did not wish to do this, it appears that I need to support
my viewpoint with references to the Debian policy documents and cite
examples of packages which demonstrate current Debian practices.
> If any program in package A requires anything that is in package B, it
> must have a 'Depends:' for package B. This is why packages depend on
> packages such as libc6 and other lib* packages and it also the reason
> why, for example, the tetex-extra package depends on the tetex-base
> package.
Incorrect. To cite the Debian packaging manual (Section
8.2. Dependencies):
------------------------------------------------------------------------
The `Depends' field should be used if the depended-on package
is required for the depending package to provide a significant
amount of functionality.
------------------------------------------------------------------------
The requirement is for the package as a whole to have a "significant
amount of functionality," not for every binary in the package to work.
The same applies to the less binding dependency of "Recommends."
> If package A will be fully functional without package B, but the
> package maintainer of package A thinks that most people who install
> package A will also need package B, package A can have a 'Suggests:'
> for package B. For example, the tetex-extra package suggests the
> tetex-nonfree package and the lprng package suggests magicfilter and
> lprng-doc. Many packages that have a separate '-doc' package suggest
> the '-doc' package.
Once again the Debian Packaging Manual says:
------------------------------------------------------------------------
`Suggests'
This is used to declare that one package may be more useful with
one or more others. Using this field tells the packaging system
and the user that the listed packages are be related to this one
and can perhaps enhance its usefulness, but that installing this
one without them is perfectly reasonable.
------------------------------------------------------------------------
First, notice that nothing here (or anywhere in section 8.2) states that
your hypothetical package A must be "fully functional" without package
B. Here it merely states that having A without B must be "perfectly
reasonable." I believe that this paragraph fully supports my position
that "Suggests" can be appropriately used to point to other packages
that add extra functionality (enhance the package's usefulness).
> On Wed, 16 Dec 1998, Brian Mays wrote:
>
> > ... The documentation, be it in html, info, or roff format, is
> > irrelevant to the package's task of fulfilling its purpose. Of
> > course, reading the documentation to know how to configure and
> > operate the software is assumed to be obvious and not deemed worthy
> > of a dependency.
>
> Yes. That's why dependencies are about programs, not documentation.
If that is so, then why do many packages "Suggest" their corresponding
-doc counterpart. As a side note, one thing that absolutely should NOT
be done is to "Recommend" or "Depend" on the documentation package.
That is very annoying.
> ... the rule is that anything that is free but depends on something
> non-free goes into contrib.
Exactly, but the key word is "depends." The policy manual only
mentions "Depends" and "Recommends" and not "Suggests":
------------------------------------------------------------------------
The Debian Policy Manual
2.1.2. The main section
-----------------------
Every package in "main" must comply with the DFSG (Debian Free
Software Guidelines).
In addition, the packages in "main"
* must not require a package outside of "main" for compilation or
execution (thus, the package may not declare a "Depends" or
"Recommends" relationship on a non-main package),
* must not be so buggy that we refuse to support them,
* must meet all policy requirements presented in this manual.
------------------------------------------------------------------------
> One of the main rules in Debian is, that _every_ package in main can
> be built from the source packages in main. Programs that need non-free
> libraries break this rule, so packages containing programs that need
> non-free libraries CAN NOT be in main.
This is not a problem. Users can, and very often do, rebuild the
pcmcia-cs package without having the xforms libraries or headers on
their system. The automatic configuration script used by pcmcia-cs is
able to detect whether xforms is present, and if not, does not build the
cardinfo binary. Of course, the newly created package does not contain
cardinfo, but since the user who built the package usually does not have
libforms installed, he or she rarely finds this a problem.
Finally, it is fairly common practice to ship executables in a package
which cannot be run unless another package, not listed in "Depends" or
"Recommends," has been installed. Often these are small scripts that
are used as an optional configuration program or provide some sort of
extra utility, and the package providing the interpreter is listed in
the "Suggests" field. Examples include c-shell scripts in dds2tar
and xtrs, an expect script in exmh, a python script in fetchmail, and
wish scripts in sgrep, chos, remind, and afbackup. Therefore, my
interpretation of the three levels of dependency definitely is how they
are used in Debian.
Brian
Reply to: