[Pkg-electronics-devel] Debian package for SystemC

Carsten Schoenert c.schoenert at t-online.de
Wed Jul 4 07:12:36 BST 2018


Hello Ahmed,

Am 04.07.2018 um 06:58 schrieb أحمد المحمودي:
...
>> you are looking for '... -version-info SCURRENT:SREVISION:$AGE' to get a
>> valid ABI versioning.
>>
>> This is a complex thing as you also need to consider a API version.
>> [...]
>> If you think you got it than you can try to adjust the upstream source
>> and upstream your modifications.
> ---end quoted text---
> 
> I am considering to ignore this issue, and rather name the library 
> package: libsystemc, or maybe even install the shared library in the 
> -dev package and drop the library package (libsystemc0), since this is 
> not a library to be linked against other software libraries or apps that 
> would be packaged in a linux distribution, it is rather a library used 
> by simulation models to be written by the users and run using special 
> simulation software (such as verilator and probably iverilog), so there 
> is no need in such case to split shared & dev packages.
> 
> What do you think ?

well, the joy of packaging upstream software that isn't in a state it
should be. ;)

You can name the library package what ever you feel appropriate.
libsystemc will be a proper name I think as there are a lot of other
library packages out there that do the same as upstream isn't providing
a API or major version within there binary naming.

Installing the shared library within a -dev package seems wrong to me
and the policy about this is rather strict.

https://www.debian.org/doc/debian-policy/#shared-libraries

The question is more if libsystemc is a public library with useful
symbols (which it is I guess) or it has no functional symbols what
qualify it as a public library. If not than it shouldn't be installed
into /usr/lib/ or /usr/lib/$multiarch and needs to go into a private
name space.

Please do not create a big package that will include all. That will
produce headache at least sometimes on third party people who have to
deal with a not ideal or correct packaging of libsystemc. It's no excuse
to say libsystemc is "special" case. There are good reasons that
software (and packages in the end) needs to fulfill the packaging
policies, if not I see no real reason why such software can't accept the
common ways of creating packages.

-- 
Regards
Carsten Schoenert



More information about the Pkg-electronics-devel mailing list