EPEL Python 3.4 for 7
a.badger at gmail.com
Tue Apr 29 15:45:37 UTC 2014
On Mon, Apr 28, 2014 at 01:45:52PM -0400, Aaron Knister wrote:
> I think it's a little unrealistic to expect the vendor to namespace their
> packages although it would be nice and probably the right thing to do.
If you buy from Red Hat, you should complain to them. That might have more
effect than I have had.
> EPEL, as the 3rd-party layered product, namespace theirs? (e.g.
> epel-python34). It's more consistent with how other packages store version
> numbers in the name
Unfortunately, this wouldn't be very consistent with the packages as
a whole. If you have a bug in the python3 package that's in
/usr/bin/python3.4, for instance, you're going to go to bugzilla looking to
file against the python34 package, not epel-python34. And we'd be doing
this for packages that we don't even build against or assume that people
have. We also have no control over what packages Red Hat will choose to
scl-ize. In the future, they could create mediawiki119 scls or Turbogears2
scls. So we really need Red Hat to stick to convention and not pollute the
> (although as an aside, the smushing together of version
> numbers without dots drives me a little crazy so part of me likes the dot in
I also like the dot in the version number in the name. However, although
that solves the problem of conflicting package names for a computer, it
doesn't solve the problem for humans. (Why do I have both python3.4 and
python34 packages installed? I should be able to get rid of one of those.)
It's also not a requirement of scls that they do not contain any dots in the
scl name. Future Red Hat supplied scls may put a dot into the name and thus
we'll still have conflicts.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 181 bytes
Desc: not available
More information about the epel-devel