On 05/19/2009 11:14 AM, Bill Nottingham wrote:
Seth Vidal (skvidal@xxxxxxxxxxxxxxxxx) 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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
