I'd suggest avoiding "native" as a term since it can be ambiguous.

--Rafael

On Fri, Oct 31, 2014 at 11:44 AM, Alan Conway <[email protected]> wrote:

> On Fri, 2014-10-31 at 11:21 -0400, Darryl L. Pierce wrote:
> > In Fedora we have the following bindings packages:
> >
> >  * python-qpid - pure Python bindings
> >  * python-qpid_messaging - Swig bindings for Python
> >  * perl-qpid - Swig bindings for Perl
> >  * rubygem-qpid_messaging - Swig bindings for Ruby
> >
> > Two issues were brought up with this:
> >
> >  1) The names are inconsistent, since Perl doesn't follow the same
> >     naming convention as Ruby and Python.
> >  2) Fedora recommends against using an underscore in a package's name
> [1].
> >
> > This last issue doesn't come up in Debian and Ubuntu since packages
> > there were never allowed to have an underscore in their name since it's
> > only allowed to be the delimiter between name and version for a package.
> >
> > To make things more consistent, and to abide by the naming rules, I'd
> > like to do the following:
> >
> >  * rename perl-qpid to perl-qpid-messaging
> >  * rename rubygem-qpid_messaging to rubygem-qpid-messaging
> >  * rename python-qpid_messagin to python-qpid-messaging
> >
> > In each case the package would continue, for two releases of Fedora,
> > to obsolete and provide the previous package to allow a transition
> > period for any other packages. But I think this would get things to a
> > more consistent and discoverable state.
> >
> > [1] http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Separators
> >
>
> I think using foo-qpid-messaging is good because it is good - these
> packages are just the qpid messaging API client. I think python-qpid is
> not good. It is also a qpid messaging API client, it doesn't have any
> other parts of qpid in it. I would suggest something like:
>  python-pure-qpid-messaging
>  python-native-qpid-messaging
> to make it clear how it differs from python-qpid-messaging.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to