[SCM] x264/master: Remove library SONAME from debian/libx264N.install file.
Reinhard Tartler
siretart at tauware.de
Fri Jan 13 14:45:50 UTC 2012
On Fr, Jan 13, 2012 at 11:28:49 (CET), Fabian Greffrath wrote:
> Am 13.01.2012 11:00, schrieb Reinhard Tartler:
>> Indeed. Maybe something based on 'find' could work.
>
> Well, that's not the problem. ;)
>
> Currently, there are three steps that I'd like to implement:
>
> 1) Dymanic generation of debian/lib*.install files with appropriate
> paths for multiarch and optimized shared libraries.
>
> Exemplarily, for libavcodec this involves renaming
> debian/libavcodec53.install to debian/libavcodec53.install.in and
> debian/libavcodec-dev.install to debian/libavcodec-dev.install.in,
> replacing the brace expansion and asterisks by something more reasonable
> and adding a rule to debian/rules to generate the former from the
> latter.
Yes, that would be great.
> 2) Removal of hard-coded SONAMEs from install files.
>
> This involves determination of the library SONAMES from the libav
> sources, renaming of debian/libavcodec53.install.in to
> debian/libavcodecN.install.in (and likewise for the
> debian/*.lintian-overrides files) and modifying the generation rule to
> take account of the SONAME.
>
> 3) Removal of hard-coded SONAMEs from anywhere.
>
> This involves renaming of debian/control to debian/control.in and
> dxnamic generation of all package names (including the *-extra-*
> variants) in debian/rules and replacement of some hard-codec references
> in debian/rules itself.
I don't think it's worth to implement 2) and 3). All libav libraries are
pretty stable SONAME wise, and I really need to know when the SONAME
changes.
> My previous approaches tried to attack all three steps at once, but I
> lost sight somewhere in the process. I'll try to implement step 1 as
> cleanly as possible and then slowly approach step 2 afterwards. Step 3
> is really tricky (although I already have a debian/control.in at hand)
> and should get postponed until the others are finished.
I agree that 1) is the only one that has priority. 2) might be nice to
have, but I don't consider it particularily important. 3) even less.
Cheers,
Reinhard
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
More information about the pkg-multimedia-maintainers
mailing list