[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Package Maintainers Flags policy

On 05/19/2009 11:14 AM, Bill Nottingham wrote:
Seth Vidal (skvidal 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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]