[Fsf-Debian] direct non-free contamination in main

Fri Nov 30 15:27:16 UTC 2012

Hi,  (somehow this mail has been blocked by spam filter.  4th try)

This is to show how small is the dependency contamination issue even if we
consider secondary alternative in depends or recommends as the dependency
contamination.  (we have over 60,000 packages).

I understand small number does not mean it does not need to be addressed.  If
FSF really think it is important not to have such in our main, this small size
of affected packages opens more chances to solve issues without much negative
impacts, I think.

(I myself do not wish to change status quo of Debian on this if FSF do not care
about this.  But I also think if we can accomodate FSF wish without much
negatives, why not do it.)

===========================================================================

Here is my summary of direct non-free/contrib contamination to the
dependency information of Debian main packages.

Short story: there are 12 packages causing this non-free/contrib contamination.
  0 packages: non-free/contrib package in automatic install position
  6 packages: migration to virtual package is possible but may face resistance.
  2 packages: migration to virtual package should face least resistance.
  2 packages: non-existing non-free packages listed many times
  2 packages: packaging change may eliminate contamination
So removing direct contamination is not a big changes if it is essential
to get FSF relationship better with Debian.

I hope this helps for discussion of http://bugs.debian.org/681419

Long story:
This data is based on the following assessment listed in BTS plus additional
manual review by me:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686481#120

The above automatic assessment in BTS did not check:
 * the package dependency induced by "provides" in the non-free/contrib package,
 * the existence of the first listed package, nor
 * the existence of the previously existed non-free/contrib package.

In a sense, this is essentially to assess if Debian system with only
"main" activated in apt shows current non-free/contrib packages in
"depends" or "recommends" field.  So non-direct contamination by
"provides" generated by non-free/contrib packages under non-free/contrib
enabled apt environment is not considered.

Results are:
 * There will be no packages listed in "depends" nor "recommends" in the
   automatic install position.
   (flexbackup NMUed and capi4hylafax about to be fixed.  Thanks Mike.)
 * 16 main packages list non-free/contrib package as an alternative choice even
   if "non-free"/"contrib" are not activated in apt.
   - 10 non-free/contrib packages are the cause of this contamination.
 * This stat misses contamination instances by sun-java5-jre and sun-java6-jre
   which are very widespread.
   (These 2 packages contaminates 34 packages as I quickly checked.)

Note: sun-java5-jre and sun-java6-jre are not available in current
      non-free/contrib.

Thus, 10+2=12 packages contaminate dependency info in main.

These 10 packages causing contamination instances can be typed as follows:

 * TYPE1: NON-FREE DATA/PROGRAM EXISTED FIRST:
   - non-free package has history behind it.
   - reverse engineering involved with the free package involved
   - non-free data/program existed first and some free alternative
     data/program were created later. (at least as perception)
   - user may be temped to use non-free for inertia.
 * TYPE2: NON-FREE DATA/PROGRAM IS ONE OF THEM:
   - non-free package is just one of them.
   - no reverse engineering involved with the free package involved
   - non-free data/program seems to offer the same functionality as other free
     alternative data/program.
 * TYPE3: PACKAGE SPLIT:
   - NON-FREE source exclusion/inclusion caused package split with virtual
     package to make free program and non-free program.

(The classification between TYPE1 and TYPE 2 is somewhat a subjective matter.)

Followings are much detailed review of each of the contamination types.

===== TYPE1: NON-FREE DATA/PROGRAM EXISTED FIRST =====
  6 packages: migration to virtual package is possible but may face resistance
  1 packages: local packaging change may eliminate contamination

==> fonts-liberation|ttf-mscorefonts-installer
DC: Package libphp-jpgraph        depends on    ttf-mscorefonts-installer in contrib
RC: Package libreoffice           recommends    ttf-mscorefonts-installer in contrib

"metrics of font" of free fonts-liberation matches non-free externally fetched
MS fonts.

See http://bugs.debian.org/691937 and http://bugs.debian.org/691945 .

==> libgl1-mesa-glx | libgl1 | fglrx-glx
DN: Package clam-networkeditor    depends on    fglrx-glx in non-free
DN: Package globs                 depends on    fglrx-glx in non-free
DN: Package libclam-qtmonitors1.4 depends on    fglrx-glx in non-free

GL driver for ATI GPU.
fglrx-glx                is a transition package to load  libgl1-fglrx-glx
libgl1                   is a virtual package provided by libgl1-mesa-glx
libgl1-fglrx-glx-virtual is a virtual package provided by libgl1-fglrx-glx

Change of the listed package name may be desirable at least:
    libgl1-mesa-glx | libgl1 | libgl1-fglrx-glx

But sorting out seemingly random virtual package names may be a good idea.

==> lesstif2-dev | libmotif-dev
DN: Package libglw1-mesa-dev      depends on    libmotif-dev in non-free
DN: Package xmhtml1-dev           depends on    libmotif-dev in non-free

MOTIF is open source but not free enough, Lestif for rescue.

==> libapache2-mod-perl2 (>= 2.0.0) | libapache2-mod-fcgid | libapache2-mod-fastcgi
DN: Package rt4-apache2           depends on    libapache2-mod-fastcgi in non-free

Not all other similar packages list these as alternatives.

==> freedoom | doom-wad | heretic-wad | game-data-packager | boom-wad
RC: Package vavoom                recommends    game-data-packager in contrib

common free DOOM engine and its game data

==> opense-basic | spectrum-roms
DN: Package fuse-emulator-common  depends on    spectrum-roms in non-free

free Sinclair ZX Spectrum emulator and its ROM firmware packages

==> ptex-bin | ptex-jtex
RN: Package yatex                 recommends    ptex-jtex in non-free

yatex is Emacs macro.

ptex-jtex does not look like such important part of functioning of yatex as
long as texlive-lang-cjk is installed.

ptex-bin is a transitional package to load texlive-lang-cjk

ptex-jtex depends on texlive-lang-cjk which should substitute ptex-bin.

texlive-bin (non-existing as binary package) may have meant "texlive-binaries |
texlive-base-bin".  But this is redundant since both texlive-lang-cjk and
ptex-jtex depends on it.

Listing emacs* is not robust.  Use emacsen.

In conclusion, I will file a bug report asking to change to:
  Depends: emacs23 | emacsen, install-info
  Recommends: texlive-lang-cjk
  Suggests: jbibtex, mendexk,  ptex-jtex, jweblint | weblint, iceweasel | www-browser, gimageview

===== TYPE2: NON-FREE DATA/PROGRAM IS ONE OF THEM =====
  2 packages: migration to virtual package should face least resistance.

==> tesseract-ocr | ocrad | gocr | cuneiform
DN: Package ocrfeeder             depends on    cuneiform in non-free
DN: Package yagf                  depends on    cuneiform in non-free
RN: Package gscan2pdf             recommends    cuneiform in non-free

==> gnuchess | sjeng | crafty | phalanx | glaurung | stockfish | hoichess | bbchess | fruit | toga2 | fairymax
DN: Package glchess               depends on    crafty in non-free

free GUI frontend common to many chess engines

===== TYPE3: PACKAGE SPLIT =====
  1 packages: local packaging change may eliminate contamination

DC: Package conky                 depends on    conky-all in contrib
==> conky-std | conky-cli | conky-all

Transitional package to load one of the three, probably conky became contrib from main
   - http://bugs.debian.org/634003 upload background
   - http://bugs.debian.org/579102 serious bug: one conky feature (build-)depends on nvidia stuff
   - libxnvctrl-dev [i386 amd64] | nvidia-settings [i386 amd64],
     ^ contrib                     ^ contrib

As I looked casually into nvidia-settings source, pertinent header file used
for building this package supporting NVIDIA feature seems to be under free BSD
license.  So including it as Debian modification to conky packakage seems to
make conky-all equivalent in main as conky or conky-std.  Then no more need to
make conky-all.  (But this resolution should be in jessie)

For now, uploading conky-all by adding "Provides: conky-std" may be an idea.

Osamu