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

[Dagobert Michelsen]

Hi Phil,

Am 15.12.2010 um 22:07 schrieb Philip Brown:
> 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

Partly, libtasn1 is old and an empty stub to libtasn1_3.
ATM there is just one SONAME in 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?

We can't do this as *devel includes *.so pointing to the soname-specific
library. If we _would_ do it all *devel-packages would need to be incompatible
to each other or distribute to specific subdirectories with the respective
development files - which would need to be specified during compilation
one by one. Sounds pretty ugly to me.

When really old versions are need the libraries should be split in a
berkeleydb-similar fashion with completely confined subdirectories.

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

...Which is clearly deprecated by package description string.

> 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

Erm, the protocol is named ASN1 - the '1' is not part of a soname number.
And yes, devel is always for the latest version.


Best regards

  -- Dago