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
