On Friday, March 2, 2018 11:32:40 AM CET Miro Hrončok wrote: > On 2.3.2018 11:25, Pavel Raiskup wrote: > > On Friday, March 2, 2018 10:36:36 AM CET Miro Hrončok wrote: > >> I've prepared a draft for Python packaging that introduces some new > >> macros that should ease packaging for Fedoras, EPELs and even potential > >> new RHELs, when it comes to python stacks. > >> > >> I don't do much ifs in specfiles and prefer to leverage git branches for > >> this, so I don't know what bothers you most. The proposal with example > >> spec file is at: > >> > >> https://fedoraproject.org/wiki/User:Churchyard/Packaging:PythonMustMayMacros > >> [..snip..] > >> Could you please provide feedback? Ask questions? > > > > What's the real usecase for *_must? > > This tells you that according to the guidelines for given distro, if > upstream supports this python version, you MUST package for it. > Some packages might want to only package their Python library for the > stacks where it's required. FWIW, I don't think macros should be used to _enforce_ guidelines (should be rather convenient things which everyone loves to use). But no problem, as long as I don't have to use that. Just saying that it might be a bit confusing when reading the (draft) wiki... > > Why the py2_must is not defined for > > epel7 and epel6? > > Because there is no such guideline. It is completely OK to package for > python3 only on EPELs. > > > I always only needed to see whether (a) python2 runtime is available, (b) > > python3 is available. So more readable and understandable approach (to > > me) would be to have only the %pyX_may (or %py3_available). But I'm > > probably not experienced enough, so I'm only curious :-). > > For that, yes. here may == available. We can discuss the naming if it > sounds weird. > > > > E.g. last time (argparse-manpage) I went with: > > > > %if 0%{?fedora} > > %bcond_without python2 > > %bcond_without python3 > > %else > > %if 0%{?rhel} > 7 > > %bcond_with python2 > > %bcond_without python3 > > %else > > %bcond_without python2 > > %bcond_with python3 > > %endif > > %endif > > > > Which allows me to do things like: > > > > %if %{with python2} > > .... > > %endif > > > > Or: > > > > BuildRequires: %{?with_python3:foo} %{?with_python2:bar} > > > > .. and which brings the convenient --with{,out}-python{2,3} options for > > custom re-builds. Could we have something similar in the draft, too? > > We can definitively make those with statemetns, however we cannot make > it with_python2 and with_python3, because we might destroy current > specfiles with that. So we would need to have: > > %if %{with python2_must} > .... > %endif > > Or: > > BuildRequires: %{?with_python3_may:foo} %{?with_python2_must:bar} > > And specifying those on the command line would be rather unreadable. > What does --with-python2-may even mean? --with-py3 or --with-py3-available doesn't soudd that bad, but .. I wouldn't worry about existing spec files.. and I would stick with --with-python2 (and friends). Existing spec files should not depend on the distro-default value, since no distro so far defined that; which means that whatever value is defined in spec file will _just_ override the new system default. For the few remaining packages (are there any?), well, there go proven packagers...? Pavel > You can always define your with_python2 based on values of py2_may, > py2_must and fedora version. > > _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
