> Matthias Klose suggested me to support wildcards in symbols files. The
> idea is that the maintainer could then create the symbols files this way:
> libc.so.6 libc6 #MINVER#
>  [EMAIL PROTECTED] 2.0
>  [EMAIL PROTECTED] 2.1
>  [EMAIL PROTECTED] 2.1.1
>  [EMAIL PROTECTED] 2.2
> [...]
> 
> dpkg-gensymbols would still generate full symbols files (with all symbols
> listed) but it would take the version from the matching wildcard.
> 
> The downside is that when using this facility, dpkg-gensymbols has no way
> to detect symbols that have disappeared since previous version.=20
> 
> I find this idea interesting to ease the work on very complex libs that
> have sane upstreams (like glibc or some gcc libs) but I'd like to have
> the opinion of others too.

Thanks for filing this report.

I came across this while writing symbol files for libstdc++6 and
libgfortran3, which differ for almost every architecture (encoding
types in symbol names, providing some symbols for a subset of archs,
e.g. ldbl symbols). Maintaining these symbol files is a pita:

 - you have to build the package for every architecture before
   uploading it to get the symbols files right for the first upload.
   Currently doing this by uploading a package which finally fails,
   after running dpkg-gensymbols (then taking the output of
   dpkg-gensymbols and updating the symbol files).

 - libstdc++6 has a 200k symbols file; multiply this by the number of
   architectures, and you triple the size of the packaging. You can
   avoid this by factoring out common symbols, but this adds another
   burden to maintain the symbols files.

afaiu the rationale for having symbols files was to get smoother
dependency information for shared libraries. This still can be done
with the wildcard approach. The check of dropped symbols could be done
by maintaining a database of symbol files for each package separate of
the package, and then check if a new upload drops symbols from a
shared library.

  Matthias







-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to