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