[pkg-gnupg-maint] dirmngr dependency

Daniel Kahn Gillmor dkg at fifthhorseman.net
Fri Aug 5 19:12:37 UTC 2016


On Fri 2016-08-05 14:42:06 -0400, Andreas Metzler wrote:
>
> typedef enum foo_args_t {
>         FOO_BLAH = 2,
>         FOO_BAR = 1
>         } foo_args;
> const char * foo(foo_args_t argument)
>
> The enum foo_args_t will be extendend (FOO_ANOTHER = 3) if foo() is
> changed to accept FOO_ANOTHER as argument. dpkg-gensymbols will not
> notice this change. However the version of foo() in the symbol file
> needs to be bumped, because a program built against the newer library
> might use foo(FOO_ANOTHER), which will only work with the newer version
> afaiui.

yes, i see your point.  There are other (non-enum) examples of API
breakage that symbols files cannot detect either (e.g. subtle changes of
semantics of the function, acceptance of NULL arguments where
non-NULL was previously required, etc).

So i tend to think of the symbols file as just being what it simply
appears to be on its face: a representation of when a given function was
first introduced.

if we wanted to represent other changes, it seems like it'd be good to
have a more explicit way to do so.

The advantage of going with the simple interpretation is that it's
mechanically verifiable, and doesn't require any additional human
insight or cognition when dealing with new upstream versions.

>> > Switching ksba to using a symbol file would have the side-effect of
>> > allowing us to enforces stricter dependencies by including
>> >
>> > * Build-Depends-Package: libksba-dev
>> >
>> > in the symbol file.
>
>> i'm not sure i understand this point.  isn't it expected that
>> libksba-dev would be the associated build dependency?  can you explain
>> more?
>
> The Build-Depends-Package line causes dpkg-shlibdeps to generate a
> dependency that is the greater of the version specified in the
> build-dependency on libksba-dev and the version that would be generated
> according to the symbol file. i.e. with gnupg2 currently having a
> build-depends on libksba-dev (>= 1.3.4) libksa8 depency would
> automatically be versioned with at least (>= 1.3.4).

oh, very cool!  this is definitely a better option.  can you point me to
where this is documented?  I've clearly read the wrong documentation (or
failed at skimming the right documentation).  Is this a change you'd
make in libksba8, or would i somehow need to do it in packages which
build-depend on libksba8 ?

With this fix, we could also treat the rest of the symbols file as a
list of versions where the function first appeared, right? :)

Thanks for the discussion, Andreas!  As usual, i'm learning good things
From talking with you.

       --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20160805/212ef443/attachment.sig>


More information about the pkg-gnupg-maint mailing list