[csw-pkgsubmissions] newpkgs libtasn1, libtasn1_3, libtasn1_devel, (...)

Philip Brown phil at bolthole.com
Wed Dec 15 22:07:47 CET 2010


On 12/14/10, Dagobert Michelsen <dam at opencsw.org> wrote:
>
> Version bump and split-off .so
>
> * libtasn1: minor version upgrade
>   - from: 2.7,REV=2010.05.21
>   -   to: 2.9,REV=2010.12.14
>   + libtasn1-2.9,REV=2010.12.14-SunOS5.9-sparc-CSW.pkg.gz
>   + libtasn1-2.9,REV=2010.12.14-SunOS5.9-i386-CSW.pkg.gz
>   + libtasn1_devel-2.9,REV=2010.12.14-SunOS5.9-sparc-CSW.pkg.gz
>   + libtasn1_devel-2.9,REV=2010.12.14-SunOS5.9-i386-CSW.pkg.gz
>
> * libtasn1_3: new package
>   + libtasn1_3-2.9,REV=2010.12.14-SunOS5.9-sparc-CSW.pkg.gz
>   + libtasn1_3-2.9,REV=2010.12.14-SunOS5.9-i386-CSW.pkg.gz
>

Coould I get some clarification here?

It's kinda wierd to see "libtasn1", and "libtasn1_3".

I'm guessing you are saying, libtasn1 holds an old, to be orphaned libxx.so.,
and libtasn1_3 is for forward use


Also, a side point about our library package naming policies in general:
I compared to debian, and they do things like

libtasn1-3
libtasn1-3-dev

Do we want to emulate that with
libXXXXn_n_devel

rather than
libXXXXn_devel
which is ambiguous and potentially confusing in situations like this?


libXXX_devel with no trailing numbering, can be more easily taken as
 "this is the appropriate modern devel for libXXX".

But your current naming, leaves ambiguity. People could misread it and
imply that for some reason, we only support devel for version 1(_0),
but not for version 1_3


More information about the pkgsubmissions mailing list