X-Original-To: alpine-devel@mail.alpinelinux.org Delivered-To: alpine-devel@mail.alpinelinux.org Received: from mail.alpinelinux.org (dallas-a1.alpinelinux.org [127.0.0.1]) by mail.alpinelinux.org (Postfix) with ESMTP id E833BDC5943 for ; Thu, 29 Oct 2015 11:14:47 +0000 (UTC) Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com [209.85.215.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.alpinelinux.org (Postfix) with ESMTPS id 79E8EDC17A6 for ; Thu, 29 Oct 2015 11:14:47 +0000 (UTC) Received: by lffz202 with SMTP id z202so16908075lff.3 for ; Thu, 29 Oct 2015 04:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kampka_net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=IdXh6zm7P3Kl1/X88LqOWhT4irhVdWM7I40676xzBC0=; b=c/+uOamwoTdgdTRzryzKNLdFa0A0QKONoVhyTK5cpT6oOUz/pnJ6rkCtDBTCCfCIlX 3m0gUhlIWSnIwuSaa3K+uoi7h7cFre8Nuz97ikay5WnPF7Db3P/b1RLLST4UK0UxrA35 tJavy6tpt4vVSsUkmekGDiUYGV0a07+ifUQYDL4t+ttwc8FMR8Ti7xKqe92WWQEwAjNw 5erxlL0oIic7Afru3/5VcFbJLAQGf5Z4WfMoOTpmCZ6cpUy/fX6mkR+c0ZNH1kAk3H5t RN7kOUftJe5M1umy9mcQ0twDAhgA7XS7WLDu9FB8sJL67r8yMF/Ou12L++XbB8PYuuop 0NhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=IdXh6zm7P3Kl1/X88LqOWhT4irhVdWM7I40676xzBC0=; b=CVVUcg/hpfdxwNXu75WHar0XSG070Y4Txsz0GscGlYX7fG8mjtKkmAcCWLH8rqINgo 3lCEw7KWCl2C6HJAoVZqVZY36066aBAoqnGAAdmHR/88QWieQo60YBem9pkGN4J+nsRn dS3rMUPWaIlB/KgYfSr8ysqlO7A1j2g02GTZLti7nwK1F440SU3OBt9OtNH1pin8Uk4l 1Dth0ZQwpXu6o9bBkiScACnR3LAbTHGY37SmWYd5OUeGuk8eJmmoMqk5xenu5BiLQRAL aHIp63X0uCsxTgr2u428tcf33BC/ggBnZamFEMaspkf2QR9tvyNKIw3LSyY9ZVwt0qQE BsYQ== X-Gm-Message-State: ALoCoQlOOvEMGLyRKjzthDXRQaom4DmqFOkr6tvNd4syfdybtMfQv9ELlMhZP+BJMDsLLX2De1ZE X-Received: by 10.25.162.21 with SMTP id l21mr429682lfe.70.1446117285037; Thu, 29 Oct 2015 04:14:45 -0700 (PDT) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 References: <20151028181756.4715b37c@vostro> In-Reply-To: <20151028181756.4715b37c@vostro> From: Christian Kampka Date: Thu, 29 Oct 2015 11:14:35 +0000 Message-ID: Subject: Re: [alpine-devel] apk-tools ideas To: Timo Teras , alpine-devel@lists.alpinelinux.org Content-Type: multipart/alternative; boundary=001a113dbf4c141e7b05233c6b1f X-Virus-Scanned: ClamAV using ClamSMTP --001a113dbf4c141e7b05233c6b1f Content-Type: text/plain; charset=UTF-8 Hi, 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. It would be great if apk would allow this. Cheers, Christian [1] http://manpages.debian.org/cgi-bin/man.cgi?query=dpkg-divert --001a113dbf4c141e7b05233c6b1f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

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/fo= o.orig instead. Any update of the package providing foo will then update th= e binary located at /usr/bin/foo.orig instead of /usr/bin/foo.=C2=A0
<= div>I find this useful for replacing binaries with wrappers that provide ad= ditional 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 pro= vide the functionality without causing a potential conflict with the apk sy= stem.