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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
