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. Could 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 (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 python3.4).
On Sun, Apr 27, 2014 at 3:49 PM, Orion Poplawski <or...@cora.nwra.com>wrote: > On 04/27/2014 07:37 AM, Aaron Knister wrote: > > > > On Apr 26, 2014, at 8:58 PM, Toshio Kuratomi <a.bad...@gmail.com > > <mailto:a.bad...@gmail.com>> wrote: > > > >> > >> On Apr 26, 2014 8:27 PM, "Aaron Knister" <aaron.knis...@gmail.com > >> <mailto:aaron.knis...@gmail.com>> wrote: > >> > > >> > We use both EPEL and SCL in my org. I didn't see this addressed in > >> the email chain but I'm concerned about what'll happen if/when SCL > >> includes python34. There are technical means to work around this but > >> it fundamentally makes EPEL and SCL incompatible. I don't believe SCL > >> is considered a layered product but maybe I'm wrong :) > >> > >> If red hat does the right thing and namespaces their scl packages then > >> there shouldn't be any conflicts. Scls are intended to be isolated > >> from system packages while epel packages are intended to integrate > >> into the system. > >> > >> -Toshio > >> > > The contents are namespaced but the package names are not. We'll end up > > with a package called python34 in each repo that are incompatible. The > > SCL package will have a prefix of /opt/rh/python34/root whereas the EPEL > > package will have a prefix of /. Undoubtedly there will be packages in > > EPEL (that aren't simply python34) modules that will require python34 > > that we'll be unable to use on systems with SCL because of the python34 > > package conflict. I wish RHEL had prefixed the package names with scl- > > but alas they did not. > > What a pain. FWIW: > > SCL 1.1: > # repoquery --whatprovides python3 > # repoquery --provides python33 > python33 = 1.1-11.el7 > python33(x86-64) = 1.1-11.el7 > [root@vmrhel7 ~]# repoquery --provides python33-python > python33-python = 3.3.2-10.el7 > python33-python(abi) = 3.3 > python33-python(x86-64) = 3.3.2-10.el7 > > EPEL7 (as currently conceived): > # repoquery --provides python34 > python(abi) = 3.4 > python3 = 3.4.0-2.el7 > python34 = 3.4.0-2.el7 > python34(x86-64) = 3.4.0-2.el7 > > So yes, we'll likely conflict on the python34 name when python34 appears > in SCL. The EPEL packages will likely simply require python(abi) = 3.4 > and python3, so that may not be an issue. > > I suppose we could use "python3.4". > > > -- > Orion Poplawski > Technical Manager 303-415-9701 x222 > NWRA/CoRA Division FAX: 303-415-9702 > 3380 Mitchell Lane or...@cora.nwra.com > Boulder, CO 80301 http://www.cora.nwra.com > _______________________________________________ > epel-devel mailing list > epel-devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/epel-devel >
_______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
