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

ppp plugins and dependencies

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

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

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.



Affected maintainers and source packages:

Christoph Biedl <debian.axhn@manchmal.in-ulm.de>

Debian FreeSmartphone.Org Team <pkg-fso-maint@lists.alioth.debian.org>

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>

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>

Chris Boot
GPG: 8467 53CB 1921 3142 C56D  C918 F5C8 3C05 D9CE EEEE

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: