[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ppp plugins and dependencies

On 07/06/15 11:49, Michael Biebl wrote:
> Am 07.06.2015 um 12:26 schrieb Chris Boot:
>> network-manager only has pppd as a Recommends despite shipping a pppd
>> plugin.
> Small correction: network-manager has a versioned Recommends and a
> versioned Breaks against ppp.
> This is deliberate, since network-manager does not strictly need ppp.
> The versioned Breaks is there to ensure that breakage due to a new ppp
> upstream version with changed plugin path does not go unnoticed.
> Unfortunately it seems ppp changes its plugin dir with every new
> upstream release.

Upstream ppp not only changes the plugin directory name but also the
value of the VERSION #define, which goes into pppd_version that pppd
looks at.

I agree that network-manager doesn't strictly need pppd to operate, and
a versioned Breaks is sufficient for this particular situation. This is
why I wanted to strike up discussion about this - we need a way of
dealing with these dependencies in such a way that works for everyone
while causing the least disruption.

[ from your follow-up ]
> Sorry, the versioned Breaks: ppp (<< 2.4.6) obviously only helps too
> ensure that a recent enough version of ppp is installed. It doesn't
> guard against breakage due to new ppp upstream releases.
> I guess I would have to add a Breaks: ppp (>= 2.4.7) for that
> Thinking about this, something like this could be useful for such
> situations:
> Breaks: != ppp-abi-version-2.4.6
> as counterpart to
> Depends: = ppp-abi-version-2.4.6

We can't do that quite, but this could perhaps be achieved with a
versioned virtual package such as (for ppp-2.4.7):

Breaks: ppp-plugin-abi (<< 2.4.7), ppp-plugin-abi (>> 2.4.7)

I don't see a != declared in the Debian Policy Manual section 7.1
either, which might have helped to condense this a bit.

Nobody wants to manage these types of dependencies by hand though, do they?

>> I was also considering writing a debhelper plugin and/or dh_ppp_plugin
>> script to help with calculating the correct dependencies at build time,
>> so that packages can simply invoke the script at build-time and Do The
>> Right Thing. It could also be used to obtain the correct plugin
>> directory to install plugins into, which seems like it would be useful
>> for network-manager-pptp among others. Does this sound like a useful
>> addition?
> Shipping a .pc file upstream to get the correct plugin directory (and
> build flags) sounds like a useful addition.

Upstream's build system is... archaic. It doesn't autotools and its
configure script is hand-built and does its own templating. I don't
think there's much scope for adding pkg-config upstream, sadly.

> The question I would ask myself, is if ppp has to break the ABI for its
> plugins with each new upstream release? Is there actually an ABI break
> in 2.4.7?

There probably doesn't need to be an ABI break for every version, but
there is with 2.4.6 => 2.4.7 due to the addition of some variables. If
this was a shared library it wouldn't necessitate a soname bump as it's
essentially just a new symbol, but a plugin that happens to use this new
symbol would break badly on an older pppd.


Chris Boot

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: