From: "Laurent Bercot" <ska-devel@skarnet.org>
To: ~alpine/devel@lists.alpinelinux.org
Subject: Re: Lets talk about apk-tools 3, and apk-tools in 2020 in general
Date: Thu, 23 Jan 2020 20:23:07 +0000
Message-Id: <em8cd27d7f-8ccd-4b31-bac7-bb20fc37b428@elzian>
In-Reply-To: <1c4796e0cda2248c2de159d4d467421c@dereferenced.org>
References: <1c4796e0cda2248c2de159d4d467421c@dereferenced.org>
Reply-To: "Laurent Bercot" <ska-devel@skarnet.org>
User-Agent: eM_Client/7.2.36908.0
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  I realize this is probably superficial compared to what you are talking
about here (it's a functional request where you are having an=20
operational
discussion), but I'm writing it here for the record.
  From a packager's point of view, there are *two* things I want a=20
package
manager to do which are missing from apk as it currently exists. So if
apk is undergoing a significant rewrite, I may as well submit the idea.

  1. A package manager should be able to handle several versions of
the same package being present on the machine at the same time. I should
be able to install util-linux-2.33 as well as util-linux-2.35, and use
programs from either version as I choose, knowing that there is one
default version, and using other versions may require a little more
effort on my part. The default version should be upgraded when the
package is upgraded, but it should also be possible to pin a default
version.
  For non-FHS installations, the functionality is easily achieved via
symlinks: /pkg/util-linux/default is a symlink to /pkg/util-linux/2.35
for instance, and /sbin/fdisk is a symlink to
/pkg/util-linux/default/sbin/fdisk. Details are easily workable.
  For FHS installations, it is more difficult to achieve, but some other
distributions have an "alternatives" feature, that still make it=20
possible
to have several versions of the same software on the machine, at the=20
cost
of being a little more annoying for the user to run a non-default=20
version
of a program.

  2. Building a package should not require root privileges, or hacks, no
matter what goes into the package. In other words: please axe fakeroot=20
in
abuild. This would, among other things, make abuild work with static
programs (as well as make abuild easier to bootstrap).
  fakeroot is used because the tar utility does not allow a non-root user
to encode arbitrary uids/gids, or certain special files such as device
nodes, in the archive. This could be avoided by having a better archive
creation tool, that takes a file hierarchy to encode as is *and also* a
metadata file, listing special permissions to modify in-archive. If you
are going to change the archive format, this is the perfect opportunity
to add the functionality, and make package creation a lot more robust.

  Thank you for considering these feature requests,

--
  Laurent