Package Maintainers Flags policy

[Toshio Kuratomi]

On 05/19/2009 11:14 AM, Bill Nottingham wrote:
> Seth Vidal (skvidal at fedoraproject.org) said:
>>>>>> If we end up needing  yum plugin of some kind to handle this can I call
>>>>>> it the free-randomstan plugin?
>>>>> We don't have a yum-patents plugin, or Provides(patents). Why are we
>>>>> going to such lengths here?
>>>> How would we have a Provides(patents) on pkgs in fedora? If the pkgs had
>>>> patent issues we couldn't ship them at all, could we?
>>> What I'm saying is that in the amount of tossing around of ideas in this
>>> thread, and the amount of work that would be required to sanely implement
>>> this (and explain it in a way that makes sense to the users) we could
>>> have fixed 99.9% of the packages to not ship flags about 5 times over.
>>>
>> I thought this thread was about explaining it in a way that our
>> developers understand it.
>
> Which 'it' here are you referring to?
>
>> I'm sorry you feel your time has been wasted.
>
> I just feel that once you've gotten to the point where we have to define
> packaging policies around magic provides, rel-eng checks to make sure that
> packages with magic provides don't end up in specific places, and then
> we may need special plugins to handle them... we've gone beyond reasonable
> solutions to the problem, and solutions that probably outweigh in effort
> and complexity the amount of work required to package things to just not
> use flags.
>
As far as I can see, these are the differences from the current policy:

1) magic provides vs magic package names
2) rel-eng checks that the magic provides aren't on the spin vs rel-eng 
checks that -flags subpackages aren't required by anything else unless 
it's in a whitelist of exceptions granted by FESCo (and rel-eng has to 
check comps to make sure there are no -flags packages listed explicitly)
3) Adding a provides to packages that have flags vs porting packages to 
make flags optional.
4) Porting packages in the main spin to make flags an optional 
subpackage -- same for each.
5) possibly a yum plugin to handle the provides vs 
nobody-thought-far-enough-ahead-to-see-that-we'd-need-a-yum-plugin-to-cover-that-case-with-naming-as-a-solution-as-well.

End result of both policies: Fedora Everything is not distributable in 
flag banning countries.  Specific Fedora spins may be.  Without a yum 
plugin, Fedora users have access to banned flag content if they want it. 
  With a yum plugin, this can be prevented... unless the user disables 
the plugin.

With provides, releng's script has to be more complex in #2.  With the 
current policy, #3 is more work for every packager that has a package 
containing flags (including maintainance to forward port our patches).

With the current policy we end up with lots of exceptions.  For 
instance, freeciv should fall under: "technically or substantively 
essential to the package".  The policy doesn't require marking these 
packages as containing flags so it needs to be updated in some manner if 
we want releng to be able to detect flag containing packages.

-Toshio