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