Hi all,
I'm emailing again because I realise I got the per-package QA email
addresses all wrong, but also because I don't think we came to any real
resolution on this.
My original message:
On 07/06/15 11:26, Chris Boot wrote:
> Hi all,
>
> Apologies for the long email, but there's a lot to discuss on the topic.
>
> Marco d'Itri and I recently agreed that I would take over maintenance of
> ppp. Thanks for all your hard work over the years keeping this package
> going, Marco.
>
> One of the first tasks on my list is to resolve the issue with
> dependencies and ABI compatibility surrounding the building of ppp
> plugins. Several packages in the archive use the ppp-dev package to help
> them build ppp plugins that are loaded into pppd at run-time using
> dlopen(). The plugins are generally installed into a particular
> versioned directory on the filesystem (currently
> /usr/lib/pppd/${abi_version}/) where pppd looks for them by default.
>
> There is currently no mechanism for binary packages to depend on a
> particular ppp plugin ABI version being available, other than manually
> creating (and maintaining) dependencies such as:
>
> Depends: [...] ppp (>= 2.4.6~), ppp (<< 2.4.7~) [...]
>
> This is easy to get wrong (in fact, only network-manager-pptp appears to
> get it even nearly right), is a pain to maintain by hand, and is
> impossible for the release team to track sensibly with the transition
> tracker.
>
> I want to fix this. I'd like to upload the new upstream release 2.4.7
> soon, but when I do this all the packages that build plugins will
> silently break. Last time we went through this pain I had to work with
> the maintainers to get fixed versions uploaded; I know I can't get away
> with it this time either, but perhaps we can make it better for next
> time especially now that ppp has gained momentum upstream again.
>
> The main problem that I see is that there isn't a built-in mechanism for
> tracking such a situation, as far as I can tell. There aren't any shared
> libraries involved, so I don't have the benefit of sonames, symbols
> files or symbol versioning.
>
> It seems I the way to resolve this might well be by using a
> "pppapi-${upstream_version}" virtual package (or perhaps a newfangled
> versioned Provides / virtual package). This appears to work for Apache,
> Perl and PHP among others. The disadvantage of this is that currently
> pppd is not a Depends for all the packages that build ppp plugins,
> unlike Apache/Perl/PHP are for their plugins.
>
> network-manager only has pppd as a Recommends despite shipping a pppd
> plugin. fso-gsmd ships ppp2fsogsmd.so and yet has no dependency on pppd
> whatsoever. Clearly, either those packages need to change or I cannot
> rely on a Depends relationship on pppapi-$foo.
>
> A ppp plugin is no use on its own, but could easily be installed and
> simply go unused without pppd installed. What definitely doesn't work is
> a ppp plugin built for a different version of pppd - the result will
> either fail to load (due to pppd's built-in version check or being in
> the wrong directory) or crash/misbehave due to an ABI incompatibility.
>
> What's the best way to handle this?
>
> 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?
>
> Lastly, pppd has a built-in mechanism for checking that loaded plugins
> are built for the correct version of pppd. It does this by looking up a
> pppd_version symbol and comparing it against its own version. Currently
> this check is optional, and is used by all the listed packages (below)
> except fso-gsmd. If it's not used, pppd prints a warning and carries on
> regardless. I wonder about making this version check a requirement to
> avoid silent ABI breakage in future. Thoughts?
>
> I very much look forward to everyone's input on these issues.
>
> If you'd like to see what's cooking so far for the next upload of ppp,
> please feel free to have a poke around the 'develop' branch in
> collab-maint/pkg-ppp.git [1]. All comments gratefully received.
>
> 1:
> http://anonscm.debian.org/cgit/collab-maint/pkg-ppp.git/log/?h=develop
>
> Thanks,
> Chris
>
> Affected maintainers and source packages:
>
> Christoph Biedl <debian.axhn@manchmal.in-ulm.de>
> pptpd
>
> Debian FreeSmartphone.Org Team <pkg-fso-maint@lists.alioth.debian.org>
> fso-gsmd
>
> Jan-Michael Brummer <jan.brummer@tabos.org>
> isdnutils (U)
>
> Michael Biebl <biebl@debian.org>
> network-manager (U)
> network-manager-pptp (U)
>
> Rico Rommel <rico@bierrommel.de>
> fso-gsmd (U)
>
> Rolf Leggewie <foss@rolf.leggewie.biz>
> isdnutils
>
> Sebastian Reichel <sre@debian.org>
> fso-gsmd (U)
>
> Simon Busch <morphis@gravedo.de>
> fso-gsmd (U)
>
> Sjoerd Simons <sjoerd@debian.org>
> network-manager (U)
>
> Utopia Maintenance Team <pkg-utopia-maintainers@lists.alioth.debian.org>
> network-manager
> network-manager-pptp
Useful discussion on debian-devel so far has suggested that:
- Upstream should ship a pkg-config .pc file (thanks Michael Biebl and
Simon McVittie in particular). I'll see what I can do with that, but
that doesn't resolve the issue of packages getting broken undetectably
when a new upstream version of ppp gets uploaded.
- Some packages can't simply use Depends like with shared libraries, as
plugins may be optional and simply provide enhanced functionality for
something, e.g. NetworkManager has a ppp plugin but doesn't _require_
ppp; a Breaks relationship works better there.
- There is an overall limitation in the current packaging tools (e.g.
debhelper) regarding how to deal with plugins or dlopen()'ed libraries.
I think it's beyond the scope of this discussion to fix this, but I'd be
happy to fork off a separate discussion on this topic.
In particular, I still don't know whether a versioned Provides would be
acceptable to use for stretch, or whether it's still considered too new?
This feels like a good approach to me, as the same Provides could be
used for both Depends and Breaks for those packages that need them.
The problem with upstream ppp sometimes needlessly breaking the ABI is
also a different question to tackle; this does sometimes happen but I
think the important point is that we can sensibly detect it and track
the transition in the release team's transition tracker. Currently such
breakages are mostly silent, which is unacceptable in my opinion.
Any further comments on this before I start uploading things?
Thanks,
Chris
--
Chris Boot
bootc@bootc.net
Attachment:
signature.asc
Description: OpenPGP digital signature