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. Cheers, Chris -- Chris Boot bootc@bootc.net
Attachment:
signature.asc
Description: OpenPGP digital signature