Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= <timo.teras@gmail.com>
Date: Sat, 31 Oct 2015 08:11:08 +0200
From: Timo Teras <timo.teras@iki.fi>
To: Christian Kampka <christian@kampka.net>
Cc: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] apk-tools ideas
Message-ID: <20151031081108.7a21ddbb@vostro>
In-Reply-To: <CADq4isTmVgVYXyXcDD=YZ5ASLA1TvUNBDpnVP2Z+jP1+th2f0g@mail.gmail.com>
References: <20151028181756.4715b37c@vostro>
	<CADq4isTmVgVYXyXcDD=YZ5ASLA1TvUNBDpnVP2Z+jP1+th2f0g@mail.gmail.com>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

hi,

On Thu, 29 Oct 2015 11:14:35 +0000
Christian Kampka <christian@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@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---