[Pkg-electronics-devel] RFS: systemc/2.3.2-2 [NEW]

[Carsten Schoenert]

Hi,

Am 24.08.18 um 13:25 schrieb أحمد المحمودي:
> Please sponsor the upload of the updated (still in NEW) package systemc
> 
> The reason I updated now is that during rebuild of systemc on the new 
> release of Ubuntu, it FTBFS because of the symbols file, I havetried 
> c++ symbol demangling on 'c++sym' branch, but it was a real pain. 
> Anyways, I suspect this problem might be the cause that systemc didn't 
> get out of NEW yet. So as you have advised on IRC today, I removed the 
> symbols file.

ah, you are the person from irc today.
The ulterior motive behind the symbols files is to helping out or to
find out the depended related libraries if I have to deal with an API
change. And symbol files from classical C files are straight forward due
the static symbols names within one API cycle.

C++ and the g++ compiler are working different here and quite often the
complete symbol name is changing between two compiler revisions. That
makes a symbol file mostly useless as there is nothing left as the
version number for a symbol.
Maintaining large libraries is really PITA. So I don't create new symbol
files for C++ libs anymore.

> Last changelog entry is:
> systemc (2.3.2-2) unstable; urgency=medium
> 
>   * Updated standards version to 4.2.0
>   * Remove symbols file, as it is a real pain to maintain
> 
> The package is lintian clean.
> 
> Or do you think that the upload better wait till systemc gets out of NEW 
> queue ?

There are different views on this, I try to prevent uploading new
versions of a package if the modifications are rather small and/or only
informative Lintian fixups. Nevertheless you can modify the packaging
within  the git tree of course.
OTOH if you have found a bigger regression or a wrong packaging than
it's in my eyes better to upload a new version to NEW and mention this
in the changelog. And also if you have a new major release taht you want
to track. But there is no rule in the policy about to handle new
packages "correctly".

In this case here I would wait a bit longer for the processing of NEW.

-- 
Regards
Carsten Schoenert

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-electronics-devel/attachments/20180824/1eda4026/attachment.sig>