Spec URL: http://peter.fedorapeople.org/erlsom.spec SRPM URL: http://peter.fedorapeople.org/erlsom-1.2.1-1.fc9.src.rpm Description: Erlsom is a set of functions to deal with XML Schema (XSDs) in Erlang. First you 'compile' the schema, and after that you can parse XML documents that conform to the schema. The result is a structure of Erlang records, based on the types that are defined by the Schema. Or, the other way around, a structure of records can be translated to an XML document.
I wonder if it wouldn't be better to name this erlang-erlsom. The only erlang package we have currently is erlang-esdl, so there's not much precedent, but it's worth considering.
I don't think that's a good idea to resolve the lack ot Groups (and absence of tags) in rpm (and therefore yum). We should populate /usr/share/doc/rpm-*/GROUPS instead of making silly prefixes as erlang-something, fuse-something, ocaml-something, perl-something etc. I think it worths to discuss in fedora-devel.
Well, I guess you're welcome to make that argument on fedora-devel if you wish. Perhaps write up a proposal to change the existing guidelines which specifically mention erlang addons. However, please note: Fedora doesn't use groups. It doesn't matter what you put there; we don't care. Your solution doesn't address issues like: ruby-gtk2, perl-Gtk2 perl-LDAP, ruby-ldap, python-ldap, php-ldap python-mecab, ruby-mecab, perl-mecab python-mechanize, ruby-mechanize So, honestly, please adhere to the current guidelines at http://fedoraproject.org/wiki/Packaging/NamingGuidelines or indicate how this package is not covered by them. (I know pretty much zilch about erlang, so maybe I'm missing something.)
So should I assume that you won't rename this package or provide some evidence that the existing guidelines shouldn't apply? If not, I suppose this ticket cannot progress and should be closed. I don't recall seeing any discussions on fedora-devel, and no proposals for changing the guidelines have come before the packaging committee.
OK, closing this ticket.
*** This bug has been marked as a duplicate of bug 502991 ***