On 24/05/11 13:31, Atri wrote:

Hi! I am trying to package [1] the scientific visualisation and data plotting software Plplot. The intention is to push it to a devel project and then to Factory by the next Milestone. However, I am facing a few problems with the naming policy to be adhered to for the shared-library and *-devel sub-packages provided by plplot. I have gone through the guidelines for shared library package names [2] and have tried to strictly adhere to it (because I want this package to end up in factory later). However, this has lead to several sub-packages having awful names such as:-

1. libplplotqtd0 : provides the shared library libplplotqtd.so.0 (I have no problem with this name, though Fedora uses the prettier name plplot-qt for this) 2. plplotqtd-devel : -devel package that depends on the libplplotqtd0 shared library alone and thus apparently has to have such a name (otherwise RPMLint complains). If I wanted to name this package as plplot-qt-devel instead, would this be possible, without violating the guidelines? (Fedora uses plplot-qt-devel, and I think that's a better name for this package)

Similarly for the sub-package plplottcltk-devel, which depends on the shlib libplplottcltk9.so.9. While I have no problem with the shlib package names themselves (as these packages will invariably be installed as dependencies and not by an user), to name the devel packages in accordance with the shlib package makes the name look awful and difficult for a user to search for the package. I would expect a user to search for the package plplot-qt-devel when he/she wants the qt development files for plplot.

If someone could tell me if it possible for the -devel package depending on a single shlib package to have a different name instead of following the shlib package name closely, without getting rpmlint to throw warnings, it would be a big help.

Thanks, and bye

-- Atri

[1] https://build.opensuse.org/package/show?package=plplot&project=home:badshah400 [2] http://en.opensuse.org/openSUSE:Shared_library_packaging_policy

If the libraries within the package are 1) tightly bound to the main program version, i.e. they release in lock-step and won't work unless versions match 2) not going to be used by any other package without having the main program as well then it should fall under the exceptions to the SLPP and you should package them within the main package (because then they aren't true shared libraries, they ideally could be packaged as modules and not installed in /usr/lib* but instead in /usr/lib/%{name} -- but that's an issue to raise with upstream) From what I would guess about your application, this is probably the case, so it's probably sufficient to have a binary package (or maybe split by frontend -qt -gtk or whatever) with a single -devel package. Easier than struggling with hundreds of packages with crazy names that would always have to be installed & removed together. Regards, Tejas -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org