I am wondering why the minesweeper feature has been included in packages
management software or its front-end.

Correct me if I'm wrong but it seems that aptitude is meant to become an
important package in future Debian distributions (i.e. called from
debian-installer and maybe even considered as a replacement for dselect).

Part of the basics of UNIX philosophy is to build programs that do only
one thing and do it well. While it is obvious that such rules can
sometimes be overruled, I can't find good arguments for this in this
case. The whole system reliability depends on package such as this one
and for that reason it doesn't look very serious to bring additional
code, documentation and complexity for a feature which is neither
necessary nor related to package management.

IMHO, OS's mechanisms such as VTs should be used and minesweeper should
be in its own package. For specific hardware or custom built kernels
where VTs are not available, appropriate mechanisms should be used.

I would like to know both the community and the author opinions about
these thoughts. If one of them agrees, then the feature should probably
be removed.

Regards,

David Orban.

I agree fully with the wish and arguments to remove minesweeper code
from aptitude.

I have also thought that its wrong to include such code in aptitude a
long time ago, but didn't bother to report a wishlist.

I wish to second the motion.

Minesweeper takes away a hotkey, never worked very well anyway
(keybindings behaved strangely - I dimly remember I had trouble escaping
out of a game), and it's needlessly adding to maintenance.

It might be nice to have while an install is in progress. OTOH there are
people who find minesweeper boring, so you'd need a general plugin for
text-based games, at which point the whole idea becomes silly.
Besides, it's a bad idea to play games during installation anyway - one
should rather be alert for error messages and questions asked.

Regards,
Jo

Indeed, it would be best to dump the fun and games and get working on these piles of real bugs!

Also remove "Super cow" insider jokes from --help.

On Sat, Aug 30, 2008 at 01:26:03PM +0800, jidanni@jidanni.org was heard to say:

  Thanks, I await your patches.

  Daniel

  I don't know why this was never closed, but it has never been a bug
and it continues to not be a bug.  There are enough real bugs that
there's no reason to keep this one open.

  Daniel

2009-02-17 03:53 Daniel Burrows:

Starting from bug https://bugs.debian.org/790568 , I had originally
said:

  > .oO I sometimes wonder if it would not be better to just remove the
  >     minesweeper altogether.  It is sort of fun/amusing and it's not a
  >     big burden to keep it going, but as cases like these show, it's not
  >     zero-maintainance either.

To add a bit about this, in the last few years (even with development
stalled for long periods of time) there were the following maintainance
costs:

- To address the bug #790568

  For the translators, this meant to translate for years strings that
  were behind "#if 0", not even used (disabling the code didn't disable
  the strings to be gathered for translation).

  That is, Minesweeper had 9 short strings to translate that were really
  used, and 21 which are actually from what it seems to be copied from
  another game / project (or a previous version of the code).

- The recent fix of the L/S ( https://bugs.debian.org/736934 ) -- back
  and forth messages and patches, applying, testing, messages in
  changelogs

- I had to spend time in the last week to make changes to the
  documentation, including links to images in the section of the
  Minesweeper (which is one of the better documented parts of aptitude,
  and with many screenshots, I have to say).

  This part has also seen translations, and we have translations to
  about 8 languages now of the guide (I guess that all of them also
  translate the part of Minesweeper, with its screenshots).

- There have been changes in translations, automake files and code in
  2012-2014


All of them are often small changes, true, and as Daniel Burrows said
most of them are part of wider changes in the source (automake, etc).
But still, even if they are mechanical changes, that means extra
mechanican changes.

And that only 15 years later a translator discovers that the bulk of the
gettext-translatable messages of this code didn't need translating
because they are not used, after almost all of the current 40 .po files
translate those lines, for me is telling that this should be disabled.


Cheers.

Another little oddity caused by this feature, it is recommended by the
meta-package games-minesweeper:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804793

Hi,

Manuel A. Fernandez Montecelo wrote:

On purpose! That was actually my suggestion.

P.S.: As stated by Markus in that bug report, it's only _suggested_,
not _recommended_ -- so it's not installed by default.

		Regards, Axel