Bug#442029: Opencity & policy: violates 9.1 & 10.7 MUSTs

Sat Sep 15 06:20:01 UTC 2007

# There's no such version in debian.
# Caused by the submitter's local package when following up.
notfound 442029 0.0.4stable-2.1
thanks

Thanasis Kinias <tkinias at kinias.org> (14/09/2007):
> My patch _does_ ship them, and I was explaining why it ships them
> where it does and not under /usr/share/games/opencity/docs:  because
> of my interpretation of the FHS requirement to put documentation _if
> installed_ in /usr/share/doc.

You don't need to yell at us defending how good your patch is, _by_
_underlining_ _each_ _single_ _word_. I can read. If you need to be said
that again: Yes, the documentation should go under /usr/share/doc. I
know that. That's just not a grave/serious bug — but I already wrote
that several times.

> This is all rather pointless, though.  I've posted a patch that fixes
> all the problems.  Can we, rather than continuing a IMHO
> not-very-helpful argument about how important the problems are, just
> _fix_ them?

Stop raising the bug severity to an overkill one, then. And let people
reading -bugs-rc fix really critical bugs instead. This bug doesn't
belong there.

> To me it's clear that the upstream author distinguished the files
> under config/ from those under, say, graphism/. I agree that _I_
> wouldn't want to modifiy config/graphism.conf, because I don't want to
> change the models used by the program.  But IIUC if I wanted to use a
> different model for, say, residential building 13, this is where I
> would modify the config.  You might argue that this file _oughtn't_ be
> modified, but that's not really the point.

It is. IMVHO maintainer opinion, a local admin doesn't have to change
this. Or grab the source, fork the game, and that's it.

> Well, it _is_ quite obvious to me.  AFAICT there is no provision for
> using a per-user dotfile and there is no (documented) command-line
> option for changing any of the settings you mention.

That's why I consider it an upstream bug, and why I'd like it to be
solved by adding upstream the possibility to scan /etc and $HOME for
other files, with an higher priority than this default one, so that
there's no need to hardcode these values in the (compiled) sources.

> config/opencity.conf is the only way to do it, and these are settings
> that a site would reasonably want to modify.  I agree that there
> _should_ be a provision to set these things by other means, but I
> don't see that upstream has implemented that, so we MUST follow policy
> and put the config file under /etc.  If we're doing that, it's no more
> work to put config/graphism.conf -- which upstream clearly considers a
> config file like config/opencity.conf -- in the same place.  My patch
> does this very easily as well as making the appropriate symlinks to
> /usr/share/games/opencity/config/{graphism,opencity}.conf.

Or, as maintainers, we may just determine that a local admin should not
modify this file, see the last lines, which are said to be important not
to change. As maintainers, we may decide that the local admin can't
change this, because it could break the game, or cause X to crash, and
because we want to avoid that.

> Is there a good reason _not_ to put them under /etc?

See above, and my other mail, I'd like upstream to do things
differently, instead of our blindly putting the config file(s) under
/etc and symlinking. Especially in the case we do that right now, and
then ship another configurable file, with different defaults, which will
lead to user prompt, asking whether s/he want to keep the older one, or
switch to the newer.

> or is this just a question again of whether or not this bug is
> Serious?  If the latter, let's drop it and work on fixing things
> instead of arguing.

It is sufficient to read this mail and the previous one(s) to understand
the point. Randome quote: “Again, I don't deny there is a bug, but
that's no violation at all.”.

BTW, you are trying by all means to demonstrate how RC this bug is,
whereas the team considers it is not, and playing severity ping-pong.
Just let -bugs-rc readers do their job.

> I read it differently.  You don't quote the sentence with the `must'
> in it:  «The following directories, or symbolic links to directories,
> must be in /usr/share, if the corresponding subsystem is installed:».
> I understand that to be that documentation _if installed_ (which is
> optional) MUST be in /usr/share/doc, not someplace else.

I understand that to be that the “doc” folder if installed must go
there. Not that static data meant to be documentation must go there. And
that's exactly why I didn't quote it, that's just irrelevant.

> Again, I'm sorry, but this IMO not a useful argument.  Can we just fix
> them instead of arguing about shoulds and musts?  I think what's most
> clear here is that Debian policy isn't as clear as it might be about
> the point.  It is _very_ clear where things are intended to go, just
> not what's SHOULD and what's MUST.

Oh, there are no longer clear and obvious violations? Good, you seem to
understand my point, now.

> I'm sorry if my initial posts on the subject struck you as
> inappropriate; my only intention was to address and fix problems I
> found with a Debian package.  I had done the work to fix the issues
> and wanted to share it with the Games Team.

Anyway, Miriam summarized the point. Your NMU sounded aggressive, as
well as your assertions about FHS violations, then you kept on raising
the severity, while no member of the team looked like agreeing with it
(see Miriam's first reaction, and I got feedback from other members in a
private manner about that too). Since you're familiar with reference
documents (I'm serious, please don't get offended), I encourage you to
go and read the “NMU” chapter of the Debian Policy (5.11)[1] and see why
that doesn't fit at all in the first place.

 1. http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu

> I'd really prefer not to argue further about the FHS severity.  Let's
> just improve Debian; that's what we're here for, no?

Exactly, and keeping the severities were they belong is one way to do
it, by avoiding flooding people working on real RC bugs (you know,
non-free material in packages, crashing applications, broken
dependencies, security holes, data loss, and the like) with normal bugs.
I've been doing that for a couple of months, and getting trivial bugs (I
didn't say that it is the case of this one) or so is realling annoying
and time-consuming.

Thanks.

Cheers,

-- 
Cyril Brulebois
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20070915/852a28b2/attachment.pgp 