[csw-pkgsubmissions] newpkgs libhistory4, libhistory5, libhistory6(...)

[Philip Brown]

On Mon, Mar 14, 2011 at 10:27 AM, Dagobert Michelsen <dam at opencsw.org> wrote:
>
> Am 11.03.2011 um 00:04 schrieb Philip Brown:
>
>> Given the naming of the other "separate" libhistory and libreadline,
>> that almost implies it is only for "libreadline".. which may make
>> people looking at "libhistory" wonder where its dev files are.
>> If you're being strictly consistent, seems like you should Either make
>> a more generic
>> "readline_dev"
>>
>> Or, make *both*
>> libreadline_dev
>> libhistory_dev
>
> This is not good. Usually we have just one -dev package regardless of the
> number of libraries involved where the name of the -dev package is
> derived from the upstream name
>and usually is lent from one of the libraries.

If there is "only one" library (which is most commonly the case), then
it can make sense to have the _dev name follow from "the library".

but I dont think this is so good  in the case where there are multiple
libraries belonging to "one" package.

I think that, if there is only going to be one _dev package that
covers all the libraries for a software group, then it makes the most
sense to name the _dev package, after the core name.

And, interestingly, although I havent made a study of all the
multi-lib splits that we have
(I suspect we have very few...)
 in at least one case, you yourself have followed this methodology :)

libpcre0-8.12,REV=2011.01.18-SunOS5.9-sparc-CSW.pkg.gz
libpcrecpp0-8.12,REV=2011.01.18-SunOS5.9-sparc-CSW.pkg.gz
libpcreposix0-8.12,REV=2011.01.18-SunOS5.9-sparc-CSW.pkg.gz
pcre-8.12,REV=2011.01.18-SunOS5.9-sparc-CSW.pkg.gz
pcre_devel-8.12,REV=2011.01.18-SunOS5.9-sparc-CSW.pkg.gz


Can we standardize on this style for naming the dev package, in the
cases of multi-library, single-dev collections?





> Splitting allows retiriing libraries one at a time. And indeed: libhistory.so.4
> is not needed anywhere, but libreadline.so.4 is, so you could skip CSWlibhistory4
> for release.

well thats good to know, thanks :)