Mail archive
alpine-devel

Re: [alpine-devel] apk-tools ideas

From: Timo Teras <timo.teras_at_iki.fi>
Date: Sat, 31 Oct 2015 08:11:08 +0200

hi,

On Thu, 29 Oct 2015 11:14:35 +0000
Christian Kampka <christian_at_kampka.net> wrote:

> since you are opening a wishlist, I'd like to see a feature that
> allows to divert binaries through apk.
> For reference, Debian offers such a feature through dpkg-divert[1].
>>
> What diversion basically provide is a way to tell apk that binary foo
> is not to be installed in /usr/bin/foo but /usr/bin/foo.orig instead.
> Any update of the package providing foo will then update the binary
> located at /usr/bin/foo.orig instead of /usr/bin/foo.
> I find this useful for replacing binaries with wrappers that provide
> additional functionality. This is typically a problem if you use
> tooling like ansible for your deployment that expects a binary in a
> certain place, eg. the apk binary.
> Tooling aside, may binaries are expected to be in a certain location,
> eg. /usr/sbin/sendmail, which is currently provided by postfix. An
> admin might want to place another sendmail in that path to provide
> the functionality without causing a potential conflict with the apk
> system.

Yes. I remember wanting to have this too. There's two current hacks:

1. busybox

Busybox has trigger and it executes always some package has
touched /usr/bin or /bin and runs busybox --install -s. Effectively
giving the possibility for packages to override bb symlinks with real
files, and if that package gets removed then bb symlink is restored.

2. java-common

Has trigger that updates the 'default-jvm' path symlink whenever java
provider dir is touched.

The down side is that bb symlinks, and the default-jvm symlink is not
"owned" by anything. So we modified "apk info -W" to show who owns the
symlink target if the symlink is not owned.

---
apk might be able to do the above by itself. It could also
automatically setup correct target for the symlink based on package
priority field. Though, if a way is needed to custom select the package
to use, it'd need some more design and addition to the database format.
I don't like dpkg-divert's way of touching installed system, and
having pkg A modify pkg B's files. Seems dpkg-divert is sort of
deprecated because of that. update-alternatives[1] is another similar
system and closer to what I'd prefer. Though it seems slightly
overkill. It'd need to be something a bit simpler still, but the
underlying idea is what I'm ok with.
Comments?
[1] http://manpages.debian.org/cgi-bin/man.cgi?query=update-alternatives
---
Unsubscribe:  alpine-devel+unsubscribe_at_lists.alpinelinux.org
Help:         alpine-devel+help_at_lists.alpinelinux.org
---
Received on Sat Oct 31 2015 - 08:11:08 UTC