[pkg-gnupg-maint] dirmngr dependency

[Andreas Metzler]

On 2016-08-04 Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> On Thu 2016-08-04 14:15:12 -0400, Andreas Metzler wrote:
>> On 2016-08-04 Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
>> I will consider this, but would probably set all version requirements to
>>  >= 1.2.0, as ABI breakage can also be caused by e.g. changed enums.
>> Testing this is not easily checked by script, and there seems to be no
>> point in making a big effort of this.

> The symbols file is specifically about the use of symbols, not about the
> use of enums.  so setting version requirements to 1.2.0 (or otherwise)
> won't actually affect the enums involved.

Hello,

I think my example was too short to be understandable, sorry. The
enum scenario was about something like this:

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.

> The symbols file is intended to record the version in which specific
> symbols were explicitly introduced.

I think that is too broad, the symbol file's purpose is to specify which
dependency info a program using the symbol should get, it tracks not
just addition of the symbol but extension which is upwards but not
downwards compatible. (See above)

> Bumping the value arbitrarily seems
> like it would "falsify" the record, and doesn't seem like it would fix
> any problems (1.2.0 is even in oldstable, fwiw).

That would imho not be an completely arbitry bump but relying on
previous work by falling back on a known, safe state. - If libksba's
current dependency information is correct, the ABI will be know to be
unchanged since 1.2.0. And I am quite sure that is the case, because I
try to check.

[...]
> aargh indeed.  i can't imagine that "things break unnecessarily" bug
> reports are more acceptable than otherwise standard dependency tracking
> :/

> I guess our choices are either:

>  a) patch out this upstream change

>  b) add an explicit runtime Depends: (which we now have to manually
>     track and update, yuck) in debian/control for gpgsm and dirmngr.

> anyone have any preferences?

c) see below.

> > 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).

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'