Re: EPEL Python 3.4 for 7

[Toshio Kuratomi]

On Sat, Apr 26, 2014 at 09:13:12PM -0600, Orion Poplawski wrote:
> On 04/26/2014 06:55 PM, Toshio Kuratomi wrote:
> > 
> > On Apr 26, 2014 11:37 AM, "Orion Poplawski"  > > wrote:
> > 
> >> One interesting change from RHEL7 beta->rc is the dropping of libdb4
> >> which python3 currently BRs, although I cannot see any evidence in
> >>
> > http://kojipkgs.fedoraproject.org//packages/python3/3.4.0/2.fc21/data/logs/x86_64/build.log
> >> of python3 actually using it (it seems to be using gdbm instead).
> >>
> > Python 3 does use libdb although I think it can use libdb5.  Python has
> > a standard library that includes both libdb bindings and gdbm bindings.
> 
> Hmm, I see no evidence that it makes use of both as currently built.  It
> seems that gdbm is preferred and there are no dependencies on libdb*.
> 
On further investigation, I see that you are absolutely right.  The bsddb
module was removed from python3.0 so we can remove the BuildRequires on db
for any python3 packages.

See the disclaimer at the top of the python2 docs:
https://docs.python.org/2/library/bsddb.html

and the PEP:
http://legacy.python.org/dev/peps/pep-3108/#maintenance-burden

-Toshio


pgpILUvRXfVH6.pgp
Description: PGP signature
___
epel-devel mailing list
epel-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Python 3.4 for 7

[Toshio Kuratomi]

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.

> 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

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
toplevel package 


> (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).
>

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.

-Toshio


pgpcMQ4X13EdP.pgp
Description: PGP signature
___
epel-devel mailing list
epel-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel