Package Maintainers Flags policy

[Toshio Kuratomi]

On 05/19/2009 07:47 AM, Ewan Mac Mahon wrote:
> On Tue, May 19, 2009 at 10:25:23AM -0400, Colin Walters wrote:
>> A list of current countries doesn't solve the problem.  Let's take for
>> example Freeciv, which was cited earlier as having flags as a core
>> part of the experience (I'd disagree, but anyways).
>>
> The problem with FreeCiv is that the only distinction between a city or
> unit of one nation and one of another is the flag[1], so there doesn't
> seem to be any simple way to remove them. They could be replaced with
> different flags graphics, but they'd all have to be distinct; you
> couldn't just use (e.g.) the Fedora logo for every nation.
>
> There's also the fact that FreeCiv in particular contains Tibet as a
> playable nation; even if the flag were removed, I don't think refering
> to the Tibetan nation would pass muster in China. That being the case
> we're either going to need to go a lot further than removing just flags,
> or accept that generic Fedora won't be 'China safe', in which case we
> might as well leave the flags alone.
>
So here's a possibility of how a compromise could be structured.  This 
is assuming that FESCo doesn't just decide that flags can be kept 
because spot's explanation in this thread clarified the legal situation:

Currently, the FESCo Policy mandates that:

1) If use of flags "is not technically or substantively essential" to a 
package, they must be in subpackages or not included.
2) Programs which require the flags must have a fallback mechanism 
because they are prohibited from Requiring the flags subpackage.
3) Exceptions are granted for programs which feel they need to violate this.

New Proposal:
[current definition of flags remains]

* Packages that include flags must show that they do this by having a 
virtual Provides: Politics(flags).
* If a package is on the main spin (or required by something on the main 
spin in the case of updates that pull in different packages), it cannot 
Provides: Politics(flags).
* If a program is needed for the main spin but Provides: 
Politics(flags), someone must do the work to move the flags into a 
subpackage that Provides the flags and patch the program to make 
existence of the flags optional.  As noted above, that subpackage cannot 
be Required from the package that is on the main spin.

Several notes:
* I divided this up a bit from the current policy.  So there's a 
political decision, no flags on the main spin, and an implementation 
decision: Use a virtual Provides to mark the packages.  I don't know if 
FESCo wants to decide the whole thing or if they want to hand off the 
second half to FPC for a solution by a certain deadline.
* Packages not on the main spin have minimal burden under this proposal
* Packages on the main spin (or packages that understand the issues and 
decide they want to be distributable in countries where some flags are 
banned) will still need to do the work, possibly carry patches, etc.
* This ties the policy to the existence of a "main spin".  I don't 
believe there's serious plans to get rid of that but if we do, this 
policy will need to be revised.
* There's no exception process like the current Policy.  The anticipated 
answer to a problematic package is: "Don't put that program on the main 
spin".
* Distributing Fedora in countries that ban certain flags is somewhat 
harder:
   - Before, a mirror could exclude subpackages that ended in -flags.
     Now the mirror would need to exclude packages that Provides: 
Politics(flags) and, to be nice to their consumers, the packages that 
depend on them.  The mirror might have gotten away with not regenerating 
the repodata with the current policy because installing an optional 
-flags package wouldn't be that common but they would definitely need to 
regenerate the repodata if the exclusion of Politics(flags): packages 
was leading to programs users might want not ending in the repository.
   - Note that you *can* still distribute the main Fedora spin without 
difficulty.

-Toshio