On Wed, Jan 28, 2015 at 11:59:01AM -0500, Bohuslav Kabrda wrote:
- Original Message -
On Tue, Jan 27, 2015 at 06:26:26AM -0500, Bohuslav Kabrda wrote:
Current state:
- Up until F21, maintainers were encouraged to build applications with
Python 2, but weren't discouraged from building with Python 3.
Note -- this isn't quite right. If an application could run with either
python2 or python3 maintainers in F21 and below were supposed to have the
app run with python2. F22 is supposed to flip this so that maintainers are
supposed make these packages run with python3 instead of python2.
I guess that I interpreted it my way since I didn't see any must in
there... But ok, thanks for the clarification :)
Yeah -- a product of Fedora Guidelines being written by different people at
different times. We don't have strict RFC-like usage of should and may in
most places. (must is usually unambiguous as to being a directive and
a bolded should, must, or may has precise meaning. Other uses (or
simple lack of any of those terms) leaves the question of how strict
a question that would have to go back to the FPC to figure out what they
meant in the past or what they want it to mean in the present day.)
- This means that packagers will be able to use the unversioned macros
throughout their specfile. Requires and BuildRequires will look like this:
Requires: %{default_python}-flask
BuildRequires %{default_python}-setuptools
Note: since BuildRequires need to be expanded in the minimal buildroot,
it's necessary to define the %default_python macro in the specfile. Other
way would be to define it in a macro file that would be added to the
minimal buildroot, but that's neither very likely nor very nice :)
Have you talked to dennis? We've added packages to the minimal BuildRoot
many times before in order to enable macro files. Not so problematic if
it's only one macro, though.
I will. Do you have any idea who I should talk to regarding EPEL? Is it also
Dennis?
Also dennis. Rel-eng is growing as a group so you could also put in
a ticket/go to one of their weekly meetings but Dennis is probably still the
one that knows the most about koji and buildroots.
I think this solution makes sense for *applications* that need to be built
both in Fedora and in EPEL. Note that it'd also align with my EPEL-python3
proposal [1], in case such an app was to be moved to python3X in EPEL
(%default_python would just be redefined to python3X). I also think that
this approach should never be allowed for packaging libraries, e.g.
packages that have python-foo and python3-foo subpackages.
Thoughts?
If we were to use different macro names instead of overwriting currently
well known ones I think this has merit.
For me, introducing yet another set of macros is unnecessary. I think that
it'd introduce a long(-ish) new part of guidelines that'll make them even
more complicated than they are right now (compared to one new macro function
and rules on how/when to use it).
Nick's breakdown of the three desired states seems like a non-complex way to
organize things. And explicit being a good thing is also a winner for me.
In addition to my original arguments that bashing existing macro names in
some spec files but not in all of them is a bad thing to force packagers to
have to deal with.
tangentially, when speaking about long-ish, though, could we use something
shorter than default_python? Maybe syspython to follow Nick's usage of
System Python?
-Toshio
pgpW94ONm2CJU.pgp
Description: PGP signature
___
python-devel mailing list
python-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel
