[EPEL-devel] Re: Virtual packages providing python2-*
On Wed, 24 Feb 2016 14:50:42 -0600 Jason L Tibbitts III wrote: > I'm actually just going to submit a review for a python2-setuptools > dummy package to take care of the most annoying case. If someone > really dislikes this idea enough to block that, then I guess I'll > find out. I guess the only issue I see with it is that it could cause confusion. ie, someone wants to remove python-foo and there's an epel provided python2-foo that they don't understand why it's there. Otherwise, it should work... kevin pgpVkZya0J65g.pgp Description: OpenPGP digital signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Virtual packages providing python2-*
> "TK" == Toshio Kuratomi writes: TK> The easiest thing to do if you want a single spec file for EPEL7 and TK> Fedora is to Requires: python-foo rather than python2-foo. Except that FPC would like to move away from this. That's the entire reason I've brought this up. Any implicit dependency on python2 should be made explicit, and the "un-python-versioned" packages shouldn't be used as dependencies unless the package really does not care which version it gets. TK> Adding extra packages has the detriment of increasing the metadata TK> size that has to be downloaded when depsolving. That is not really much of a concern in a universe where we have texlive. TK> 166 packages might not be so bad... Or as you say, just doing a few TK> high value ones like python2-setuptools might be the best of both TK> worlds, providing compatibility for the most common cases but not TK> adding significantly to the metadata. I'm actually just going to submit a review for a python2-setuptools dummy package to take care of the most annoying case. If someone really dislikes this idea enough to block that, then I guess I'll find out. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Virtual packages providing python2-*
On Tue, Feb 23, 2016 at 2:00 PM, Jason L Tibbitts III wrote: > One annoying difference between packaging for Fedora and EPEL7 (and > probably older) is the fact that Python packages in Fedora are required > to provide "python2-foo" whereas many EL7 packages don't. This leads to > ifdefs and unpleasantness, and kind of complicates our ability to hide > some details behind macros. > The easiest thing to do if you want a single spec file for EPEL7 and Fedora is to Requires: python-foo rather than python2-foo. The packaging guidelines say that the python2 version of the module should provide both python-foo and python2-foo (one of those being the package name and the other a virtual provide) > As I see it, the easiest way to hide this (besides RH maintainers > updating those packages with the extra Provides:) is to add a bunch of > empty packages named "python2-foo" which have nothing but a dependency > on "python-foo". > Adding extra packages has the detriment of increasing the metadata size that has to be downloaded when depsolving. > > Even just getting python2-setuptools in would eliminate a lot of cruft. > There are, I believe, 166 packages which might need this, though we > don't have to add them all at once if that makes things more palatable. 166 packages might not be so bad... Or as you say, just doing a few high value ones like python2-setuptools might be the best of both worlds, providing compatibility for the most common cases but not adding significantly to the metadata. -Toshio ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Virtual packages providing python2-*
On 24/02/16 13:41, Peter wrote: > Maybe I missed something here. I just realized I completely missed the point of this, never mind my post above it's based on a complete mis-understanding. Peter ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Virtual packages providing python2-*
> "P" == Peter writes: P> I would be worried, though, that you'll have packages that were built P> against python that are now trying to pull in and possibly run on P> python2 unnecessarily, and possibly detrimentally if Red Hat suddenly P> decides to push python2 packages out. I can't imagine a situation where that would happen. Perhaps you could give an example which you believe I haven't provided an accounting already. P> It seems to me that if the package is going to be built against P> pythin then it should require python, if it has to be built against P> python2 then it should require python2. I'm not understanding the issue here. python _is_ python2 and that isn't going to change for RHEL7 within its lifetime unless Red Hat really does bizarre things, and then we'd adapt. I just don't see Red Hat going so significantly against established Fedora packaging guidelines here. (Any package that needs the python3 version of something absolutely must require python3-something. It will never be acceptable for it to depend on python-something and expect that to be python3.) P> In neither case does it seem prudent to be tricking packages into P> thinking that python is actually python2. I don't see how anything is being tricked anywhere. This is adding just one thing: allow you to access python-foo via the package name python2-foo so that we don't have to have ifdefs. - J< ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Virtual packages providing python2-*
On 24 Feb 2016 17:12, "Jason L Tibbitts III" wrote: > > You took this off-list; was that intentional? Feel free to forward my > message back to the list if you wish. > > > "JH" == James Hogarth writes: > > JH> I suppose having the guidelines prefer requires on python-foo rather > JH> than python2-foo, which would also solve this, only just kicks the > JH> ball down the road a little and makes a system default switch harder > JH> beyond the foreseeable future. > > Right; we really want to get away from anything having dependencies on > the "un-python-versioned" packages or even using the "unversioned macros" > unless they really do not care which "python-version" of a package they > get. And even then, it would be far better to just make it explicit. > > JH> Surely you mean supplemented with new python libraries brought into > JH> base? > > Well, if additional packages crop up which would need dummy packages > then obviously we could add them. It would be kind of obvious when > someone tries to build something for EPEL7 and finds that they'd need to > add a conditional to get the "un-python-versioned" package, at which > point they could simply ask for the dummy to come into existence. > > JH> Unless you envision internally at Red Hat the specs there > JH> being changed in a future milestone to provide the python2-foo stuff > JH> in addition to python-foo and being more similar to the Fedora/EPEL > JH> packages? > > Well, it sure would be nice. > > JH> Are you planning this for EPEL6 as well or just EPEL7? > > I wasn't, but I could. > > JH> Admittedly packaging for EPEL6 means a lot of conditionals anyway if > JH> the spec files weren't separated in the first place... > > We're trying to eliminate as much of that as possible. It's a long > process. > > JH> If the version of python2-foo is set to zero how do you picture > JH> Requires: python2-foo >= 0.4 being resolved? > > Not sure. I'm also not entirely sure it matters; either the version you > need is available in RHEL or there's no point in building the package. > And if it does matter, all we have to do is pick the same version as the > base RHEL package with a lower release (probably just 0). > > - J< Replying to get this back on list... Apologies was responding on my tablet and didn't notice it defaulted to reply, not reply all, unlike my desktop... ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Virtual packages providing python2-*
On 24/02/16 13:09, Jason L Tibbitts III wrote: > JH> How should this be maintained going forward into 7.3+ in case RH > JH> bring more into base... > > They would be removed. If we set the version of the dummy package to > zero, they won't even get in the way if a RHEL package does start > providing python2-whatever, since the RHEL version would then always > take precedence. I would be worried, though, that you'll have packages that were built against python that are now trying to pull in and possibly run on python2 unnecessarily, and possibly detrimentally if Red Hat suddenly decides to push python2 packages out. It seems to me that if the package is going to be built against pythin then it should require python, if it has to be built against python2 then it should require python2. In neither case does it seem prudent to be tricking packages into thinking that python is actually python2. Maybe I missed something here. Peter ___ epel-devel mailing list epel-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Virtual packages providing python2-*
> "JH" == James Hogarth writes:
JH> Do just to be clear from your wording you are talking about RHEL
JH> python packages that are known as python-foo in RHEL rather than
JH> python2-foo there, since there is no other python within base to
JH> cause confusion?
Right, there are 166 such packages. And the issue isn't the name of
those packages; it's whether you can expect to have some dependency on
python2-foo satisfied on both Fedora and EPEL7. Fedora would like to
start moving towards that in the near future.
JH> Of course by guidelines python- on Fedora should be pointed at
JH> python3- these days as that's the default runtime - correct?
python3 is not the default runtime in any release of Fedora. (It's
still python2 and will remain as such for the forseeable future.) The
default runtime is defined as the target of the /usr/bin/python
symlink. That's different from what we say about which version of
Python a package should be using if it supports both. (That's python3.)
The packaging guidelines don't indicate what packages should Require:.
They don't really say what they should BuildRequires:, either, besides
python2-devel or python3-devel. We are trying to move towards
increasing stricture here, but first we wanted to mandate that
everything actually Provides: python2-* first. Since we can't depend on
RHEL ever doing that, any stricture we do introduce in the future will
cause additional headache for EPEL packages.
I'm just trying to head that off before it starts getting bad.
JH> So these proposed would be not actually conflicting with base (no
JH> python2- in base) but just sort of supplementing them to make
JH> packaging EPEL python stuff easier on dependencies with less %if
JH> {?el6} conditionals?
Exactly. I obviously don't want to introduce any conflicts, and they're
against the EPEL guidelines in any case.
JH> How should this be maintained going forward into 7.3+ in case RH
JH> bring more into base...
They would be removed. If we set the version of the dummy package to
zero, they won't even get in the way if a RHEL package does start
providing python2-whatever, since the RHEL version would then always
take precedence.
JH> Unless you want to handle checking each milestone for fresh
JH> python packages to dummy?
Yes, that was the scripting I mentioned. It's not particularly
difficult to see which python-* packages currently provide python2-* and
to compare those against the list of dummy packages we're providing.
It's not tough to check regularly and this should be done even if any
possible conflicts are harmless.
JH> In principle I think it a worthwhile endeavour in practice I think
JH> it might complicate bug reporting to the correct component (EPEL vs
JH> RHEL and any future python packages missing it).
Not sure how this is any different from anything with a similar name to
something in EPEL. If there are any misreported issues, it's a pretty
quick click to change the component. I don't really expect that this
would cause much in the way of problems, though, since these packages
would never show up in the deplist of any RHEL package, and they contain
no files so any automatic bug reporting setup wouldn't involve them.
- J<
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Virtual packages providing python2-*
On 23 Feb 2016 22:00, "Jason L Tibbitts III" wrote:
>
> One annoying difference between packaging for Fedora and EPEL7 (and
> probably older) is the fact that Python packages in Fedora are required
> to provide "python2-foo" whereas many EL7 packages don't. This leads to
> ifdefs and unpleasantness, and kind of complicates our ability to hide
> some details behind macros.
>
> As I see it, the easiest way to hide this (besides RH maintainers
> updating those packages with the extra Provides:) is to add a bunch of
> empty packages named "python2-foo" which have nothing but a dependency
> on "python-foo".
>
> I can get a review process exception from FPC and script up the import
> of these things pretty trivially. The question is: would anyone object
> to this? Obviously we'll have to have some way of detecting any
> conflicts which might arise, which can be done pretty easily with some
> scripting.
>
> Even just getting python2-setuptools in would eliminate a lot of cruft.
> There are, I believe, 166 packages which might need this, though we
> don't have to add them all at once if that makes things more palatable.
>
> And if there's a need to discuss this at a meeting, could someone add it
> to the agenda (and remind me of the meeting time)?
>
>
Do just to be clear from your wording you are talking about RHEL python
packages that are known as python-foo in RHEL rather than python2-foo
there, since there is no other python within base to cause confusion?
Of course by guidelines python- on Fedora should be pointed at python3-
these days as that's the default runtime - correct?
So these proposed would be not actually conflicting with base (no python2-
in base) but just sort of supplementing them to make packaging EPEL python
stuff easier on dependencies with less %if {?el6} conditionals?
How should this be maintained going forward into 7.3+ in case RH bring more
into base... There wouldn't be an EPEL component for that item. Unless you
want to handle checking each milestone for fresh python packages to dummy?
;)
In principle I think it a worthwhile endeavour in practice I think it might
complicate bug reporting to the correct component (EPEL vs RHEL and any
future python packages missing it).
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org
