Every day cron sends a report about dangling symlinks in mingw32 (only
since updgrade from previous version, FWIW):
/usr/share/man/man1/
    i586-mingw32msvc-c++.1.gz -> i586-mingw32msvc-g++.1.gz
    i586-mingw32msvc-cc.1.gz -> i586-mingw32msvc-gcc.1.gz
    i586-mingw32msvc-cpp.1.gz -> cpp.1.gz
    i586-mingw32msvc-gcc-3.4.5.1.gz -> i586-mingw32msvc-gcc.1.gz
    i586-mingw32msvc-gcov.1.gz -> gcov.1.gz

gcov is not installed on my system, so it should not make the link.
cpp is installed (4.1) but apparently misses a man page !
3 others are intra-package dangling links, so should be corrected.

More generally, the package should provide its own copy of man pages,
because when you link to "cpp" or "gcov" you don't know which version you
get (several are provided in testing), and bets are you won't get the one
that matches mingw32's.

cpp has a man page, you are apparently missing the cpp-doc package ;-)

Except in this case removing them is precisely all the last upload did.
These files are licenced under the GFDL with invariant sections and so
cannot be distributed in main as DFSG Free Software.  I guess we'll just
remove the offending $target- aliases too.

The differences are not that great, and even less likely to get you into
trouble or mislead you in practice.  But if the links aren't helpful any
longer there is little reason to keep them...

Cheers,
Ron

We believe that the bug you reported is fixed in the latest version of
mingw32, which is due to be installed in the Debian FTP archive:

mingw32_3.4.5.20060117.1.dfsg-2.diff.gz
  to pool/main/m/mingw32/mingw32_3.4.5.20060117.1.dfsg-2.diff.gz
mingw32_3.4.5.20060117.1.dfsg-2.dsc
  to pool/main/m/mingw32/mingw32_3.4.5.20060117.1.dfsg-2.dsc
mingw32_3.4.5.20060117.1.dfsg-2_amd64.deb
  to pool/main/m/mingw32/mingw32_3.4.5.20060117.1.dfsg-2_amd64.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 404116@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ron Lee <ron@debian.org> (supplier of updated mingw32 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)
Format: 1.7
Date: Sat, 23 Dec 2006 15:13:58 +1030
Source: mingw32
Binary: mingw32
Architecture: source amd64
Version: 3.4.5.20060117.1.dfsg-2
Distribution: unstable
Urgency: high
Maintainer: Ron Lee <ron@debian.org>
Changed-By: Ron Lee <ron@debian.org>
Description:
 mingw32    - Minimalist GNU win32 (cross) compiler
Closes: 404116
Changes:
 mingw32 (3.4.5.20060117.1.dfsg-2) unstable; urgency=high
 .
   * Very minor changes, but urgency remains high as they are errata for the
     previous upload.
   * Bump standards version to 3.7.2.2
   * Suggest the gcc-doc and cpp-doc packages.
   * Fix the symlinks broken by removal of the documentation.  Closes: #404116
Files:
 217dff9d6f9bbba81eca18ead7d259d0 674 devel optional mingw32_3.4.5.20060117.1.dfsg-2.dsc
 6d5113a977a3f1ee51e82edbfd58e640 6688 devel optional mingw32_3.4.5.20060117.1.dfsg-2.diff.gz
 54d277b390e0217466b2d69ab95420e0 11035572 devel optional mingw32_3.4.5.20060117.1.dfsg-2_amd64.deb
iD8DBQFFjLdAp4BCHGgCHOQRAuRrAJ9hL1ljimfky/8sKhq6RCVnYlHmJwCfaCR+
BqbkIzz9BibwQpAw8b0Lkq8=
=sOdp
-----END PGP SIGNATURE-----

found 404116 3.4.5.20060117.1.dfsg-2
thanks

I'm still getting daily spam from cron about:

        $ ls -l /usr/share/man/man1/i586-mingw32msvc-cpp.1.gz
        lrwxrwxrwx 1 root root 8 2006-12-25 21:25 /usr/share/man/man1/i586-mingw32msvc-cpp.1.gz -> cpp.1.gz

Perhaps follow the package's Suggests and install the cpp-doc package?

 Ron

reopen 404116
thanks

Should be Depends then!  Otherwise please move the symlinks to
mingw32-doc or something.

No it shouldn't:

 2.2.1 The main category
 ...
 In addition, the packages in main

    * must not require a package outside of main for compilation or
      execution (thus, the package must not declare a "Depends",
      "Recommends", or "Build-Depends" relationship on a non-main
      package),

The Suggests seems like a friendly compromise between "every binary
should have a man page" and the fact that the man pages have been
declared non-free.

I could remove the links entirely and simply accept the former bug
until we have free docs again, but I really don't think this is worth
an entirely new non-free source package, just for a couple of symlinks.

Unless someone has a better idea, the existing situation of pointing
people to the docs, and providing the hooks to use them should they
choose to install them seems to be the most user and archive friendly
thing I can do, given the very messy set of circumstances that has
evolved around this.

This package has had to skirt the undefined edges of policy since its
first upload.  If it becomes untenable to continue to do that then I
will have to give serious consideration to simply removing it from
the distro entirely.  It's been quite a while since I've needed to
support anything for its target platform, but I continue to maintain
it because not all of our users are that lucky yet.  Supporting them
is still something of a "best effort" game, since our policy isn't
exactly designed around packages like it, and on the principle of
"hard cases make bad law", nor should it be.

I try to make it fit as well as I can.  If someone has a practical
suggestion for ways we can do that better then I'm all ears, but in
the meantime, occasionally I need to be pragmatic about what actually
supports its users the most effectively, with the least impact on the
distro proper.

Cheers,
Ron

reopen 404116
thanks

Please don't close it.  That we haven't found a good solution doesn't
mean that there is no bug.

Oops, I missed the part about cpp-doc being in non-free.

Why don't you check in postinst wether the actual manpages exist, and
set the symlinks only if they do?

cpp-doc postrm could check wether someone is linking to its manpages,
and remove the links if applicable.

We'd have to pre-depend on a non-free package for that to be reliable
though.  A well defined, easy to remedy bug that skirts around policy
seems preferable to an intermittent one that requires a forced reinstall
or The Big Hammer to fix.

If this were a general issue, that might be an option to explore, but
afaik its only this package affected, so I'm not terribly keen on the
idea of infecting another package with a workaround also...

Maybe I'm wrong but I'd guess a large proportion of people using this
would also tend to have the toolchain docs installed.  For those that
don't want them, they are pretty certain to have the rm tool handy ;-)

That's not the sort of answer I'm typically fond of, but it works for
those who thought they already had the docs and install them when the
dangling links point that out, as well as being a well known generic
solution for dangling symlinks left by whatever means as happens from
time to time...

In the absence of a real solution, that seems pretty close to line of
least surprise.  I'll leave this open in case someone comes up with
one though, and to document the present best fix.  I will summarily
close future reports from people who didn't read it though ;-)

Cheers,
Ron

Suggests is enough.  You don't need to rely on cpp-doc's postinst having
been executed (since manpages are part of data.tar.gz), so if cpp-doc and
mingw32 are installed in the same run, everything is ok:

thread1:  install cpp-doc data.tar.gz
thread2:  install mingw32 data.tar.gz

synchronization

thread1:  process cpp-doc postinst
thread2:  process mingw32 postinst.  cpp-doc's data.tar.gz is granted to
  be installed.

Anyway, I think it's a much worse bug to spam users with daily rubish email
than to ship a package plainly without manpages.  So if you have to choose,
I'd pick the latter (the average mingw32 user is smart enough to figure out
that gcc/cpp docs will work fine for *-gcc/*-cpp equivalents).

A package in main that causes cron to spew these messages unless a package
in contrib is installed, is broken. Not installing Suggests is not intended
to leave the system in this kind of state.

mandb: warning: /usr/share/man/man1/i586-mingw32msvc-gcc-3.4.5.1.gz is a dangling symlink
mandb: warning: /usr/share/man/man1/i586-mingw32msvc-cc.1.gz is a dangling symlink
mandb: warning: /usr/share/man/man1/i586-mingw32msvc-c++.1.gz is a dangling symlink
mandb: warning: /usr/share/man/man1/i586-mingw32msvc-gcov.1.gz is a dangling symlink
mandb: warning: /usr/share/man/man1/i586-mingw32msvc-gcc.1.gz is a dangling symlink
mandb: warning: /usr/share/man/man1/i586-mingw32msvc-g++.1.gz is a dangling symlink
mandb: warning: /usr/share/man/man1/i586-mingw32msvc-cpp.1.gz is a dangling symlink

It would be acceptable to replace these symlinks with short man pages
that point to cpp(1) etc for detailed documentation.

In the meantime, I'm purging this package. :-/

Fair comments, I don't disagree with that.

Policy is probably ok with that, but with the benefit of more time to
think on this, I'm not sure that I am.  Not having free documentation
for our primary toolchain _is_ a serious bug IMO.  So I think I'm leaning
toward the 'purge the symlinks and retitle this bug "binary w/o a manpage"'
solution, in preference to the 'cover the gaps, close the bugs, pretend its
all ok' path.

I'm sure we'll have free documentation again eventually.  I just don't
know when.  This really is an open issue (and a pita) until we do...

The bug can remain open as a reminder to all, it will just be a little
less annoying on a daily basis than the present solution.  Most people
using the toolchain can probably map foo-gcc to gcc(1) in their heads
without too much prompting, and it would probably be a safe bet the
majority already do rather than typing the full foo- alias.

If I'm still convinced of this at the next upload, that's what I'll do
then ...

If you really need it in the meantime, rm works on these symlinks the
same as for any other broken package that left them dangling or forgot
them in a purge.  ; )


Thanks for your input just the same, its hard to judge lesser evils from
just a small sample of opinions.  In hindsight I agree the convenience to
people who do install the non-free docs does not balance the inconvenience
to those who don't with the present arrangement.

Cheers!
Ron

retitle 404116 binary without free documentation
thanks

As previously discussed, the symlinks to non-free documentation
have now been removed and this bug is being retitled to reflect
the remaining fundamental problem.

 Ron