Package Maintainers Flags policy
a.badger at gmail.com
Tue May 19 19:27:35 UTC 2009
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
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
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.
More information about the fedora-devel-list