On Wed, Feb 08, 2006 at 11:43:22AM +0100, Filip Van Raemdonck wrote: > On Wed, Feb 08, 2006 at 11:43:26AM +1030, Ron wrote: > > So my choices would be: > > > > a) Close this report and leave it as it is. People who expect > > gccbug and are familiar with its use will probably find the > > dangling link does what they might expect. > > It's annoying to leave the link because it gets found by a few cron > scripts and may be the only cause of output, meaning a mail gets send over > nothing really.
You are probably in a small minority if you have mingw but not gcc, but I must agree we should not be the cause of that. Especially as it will keep getting sent on a regular basis. > > c) Modify the upstream distribution further during the package > > build to purge any reference to gccbug. > > > > Which would you prefer? > > Of these c makes most sense. > > You forgot one (though I don't think it is a better choice than c for > reasons you mentioned above): > > d) Modify the upstream distribution further during the package build to > not symlink to gccbug but include the actual manpage, as other gcc > provided manpages already are. (meaning, i586-mingw32msvc-gccbug.1.gz > becomes a manpage of itself) I didn't forget it, it just didn't survive past the preamble: > > On Tue, Feb 07, 2006 at 03:24:33PM +0100, Filip Van Raemdonck wrote: > > > > > > The mingw32 package contains a symlink > > > /usr/share/man/man1/i586-mingw32msvc-gccbug.1.gz which points to > > > gccbug.1.gz in the same directory, but I have no such page on my system > > > (likely because I have no native gcc installed). > > > > > > Since the package includes full manpages for the other i586-mingw32 > > > commands, it probably should for gccbug too. > > > > Well, it probably can't supply gccbug.1.gz, as that may conflict > > with a native package as you suggest -- and given that it probably > > doesn't do what we would want anyway, except in the hands of an > > expert user (mingw's bts is on sf, and we have reportbug et al. > > for ours); then if this is a bug, I guess the solution is to simply > > remove all i586-mingw32msvc-gccbug related bits from the package. > > > > If someone knows of it AND (rightly) thinks the bug they found in > > mingw should go directly to upstream gcc-maint using it, then they > > probably also have it installed. Otherwise, by default, we should > > probably steer reports related to this package back through the > > people who have added additional layers to it. I don't think gccbug is really very helpful for this particular package, my guess being it would be more likely to misfire than direct an issue to the correct place. While it proved harmless, I had no itch to add more things to be maintained, but I don't think keeping it justifies extra work. If there is extra work to be done, we should prune it away before it causes real mischief. I'll look at c) for the next upload unless new information compels a better option. Thanks! Ron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
