On Aug 19, 2015 8:10 PM, "Parag Nemade" <panemade@gmail.com> wrote:
>
> Hi,
>
> On Wed, Aug 19, 2015 at 12:29 AM, Matthew Miller
> <mattdm@fedoraproject.org> wrote:
> > On Tue, Aug 18, 2015 at 01:22:59PM +0530, Parag Nemade wrote:
> >>    Sometimes I get confused how to handle naming of a package where
> >> package itself provides a nodejs or python library and wrapper/tool to
> >> use that library.
> >>    We have guidelines where it says if source is library from npmjs or
> >> pypi then we should prefix package with nodejs or python but how to
> >> name when source contains both?
> >>    What gets precedence? name them with prefixes or just by tool name
> >> or library name?
> >
> > Subpackages are definitely the answer here. There are still several
> > rational options. If the tool is primary, making the main package be
> > the upstream name ("foobar") makes sense, with subpackage for the
> > library ("python3-foobar", "foobar-libs"). If the library is primary,
> > though, you might want to go for "libfoobar" and "libfoobar-tools".
>
> Thanks. I have too followed same thing for some of my packages
> recently. Here what I want is, is this written somewhere? Just to give
> reference to package submitter if he want some official source during
> package review.
>
> I can't find such explanation in python packaging guidelines wiki page
> and also not in
> https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Addon_Packages_.28python3_modules.29
> page.
>
> Can some one if possible add this naming information there? Or do I
> need to file a ticket on fpc for this?
>
In current guidelines, libraries and applications are allowed to mix in the same (sub)package.  For c packages, we've slowly gotten away from this practice due to multi lib.  But no such technical reason for demanding packages split binary and library exists for python, ruby, Perl, nodejs, etc.

It's (a little) more work to split every package that ships a small script along with its library.  So traditionally we don't make that demand..  if the application is important enough and the library is just implementation detail then we have the package ship everything under a non-prefixed name.  If the library is most important and the script is along the lines of a usable example of what you can do with the library then we use the python- prefix.  We don't really talk about the case where application and library are of equal value but packagers are expected to use good judgement and probably should use subpackages to address the situation.

There is a lot of grey area between these three points of interest.  I wouldn't be opposed to the guidelines being updated to either eliminate some of them  (for instance, libraries and "binaries" must always be in separate subordinates) or for a more comprehensive description of when to use each style of packaging.  I'd only ask that this be applied to all packages, not just python and nodejs.  It really is a style issue that should apply to similar packages in all languages.

-Toshio