Another problem with building your own packages: dependency issues

May 6, 2014

I've written before about how I feel being forced to build software yourself is a waste, but this is not the only problem with the 'make our users build things themselves' approach to system packaging. Another one is interlocking dependencies, where OS packages depend on things that you (the end sysadmin) may want to replace with your own stuff.

Suppose that the base operating system supplies both a minimal mailer package and a 'smtp-notifier' package that sends mail when alert-worthy system level things happen, like faults being reported through the OS's fault management system. However you (the sysadmin) want to use an entirely different mailer, which is clearly not going to come from the OS's package set (the OS packaged only the minimal mailer it 'needs') and might even come from a completely different packaging system than the OS's one.

At a minimum there's a dependency issue here. A naively done smtp-notifier package will insist that you install the system's undesired mailer. Even a relatively sophisticated one is likely to insist that you install your choice of mailer using the OS's native packaging system so that it knows that smtp-notifier's dependency is satisfied. Of course life gets worse if you're not really supposed to install your things in the OS's directory hierarchies; how does smtp-notifier even find the right mailer binary to use? Normally it has every right to expect that said binary is living in the OS-owned area of the filesystem hierarchy.

All of this is solvable with effort, but it does require effort and it requires this sort of dependency interlock issue to be anticipated by the people who build OS packages and write the OS package manager. If they did not, you probably get to chose between smtp-notifier and your mailer.

Broadly speaking this sort of dependency issue can happen to anything that you can only really have one of on the system and that may be used by other OS packages (either directly by invoking its programs or indirectly by, eg, TCP services). Mailers are an obvious case because a lot of things want to send email (unless you deliberately make them less useful by breaking that).

PS: to be fair I'm not sure if this issue is really likely to come up for anything other than mailers, especially in OSes with minimal native package sets. They seem unlikely to have, eg, web-based management systems that require the OS-packaged webserver.


Comments on this page:

By bdwalton at 2014-05-06 02:50:56:

This sounds like Solaris vs exim...

My solution was to leave /use/lib/sendmail in place as the system mailer, but with a configuration that saw anything injected through that binary forwarded into a localhost:25 bound exim daemon. That allowed using sane configuration while not suffering pain at every OS upgrade that would happily overwrite any replacement of /use/lib/sendmail with an alternate binary or symlink.

Some version of Solaris added a special SVC for this usecase. (I've forgotten the name.) That at least shows awareness of the problem.

-Ben

By dozzie at 2014-05-07 02:26:31:

PS: to be fair I'm not sure if this issue is really likely to come up for anything other than mailers

Yes, it is likely. For libraries, if you happen to need a newer version of something that is already installed. I have run into this problem several times already.

By cks at 2014-05-07 10:09:12:

I don't think this issue affects libraries under normal circumstances. The problem with a mailer is that it's exclusive because eg only one thing can listen on port 25. Libraries are not exclusive in this way; you can have your own set installed in /opt and ignore the system's set (and minimal base OSes generally expect or require you to do this).

Written on 06 May 2014.
« The power of meaningless identifiers
How I use Unbound on Fedora 20 to deal with the VPN DNS issue »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue May 6 00:10:37 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.