Re: Bug#30739: When a tiny part of a package uses non-free libraries
On Wed, 16 Dec 1998, Brian Mays wrote:
> 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.
Please note that I was writing all of this from the top of my head, so
don't take it too literal.
> > 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):
<snip>
> 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."
"Providing a significant amount of functionality" includes "running", IMO.
And that applies to _all_ programs in the package.
> > 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:
<snip>
> 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).
"More useful" implies that it would be "useful" without those "others".
And "useful" implies "working".
> > 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.
Ehm, here I meant to say something about "Depends:", not all three levels
of dependencies in general.
> > ... 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),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is exactly what I have been trying to say all the time.
> * 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.
This is not the point. A package that was built this way, can go into
main. But if a package contains the cardinfo program, xforms was needed to
build that package, so it can not go into main.
Again, there are two choices:
1. Create a separate package for cardinfo and put that in contrib.
2. Move the whole thing into contrib.
Remco
(tired of repeating himself so often)
Reply to: