Re: [alpine-devel] Adélie on Alpine, two months later
On Mon, Jul 24, 2017 at 10:20 AM, A. Wilcox <awilfox_at_adelielinux.org> wrote:
>>> 2. The virtual system is pathetic. One of the very core tenets
>>> of Adélie is giving the user power through choice. That choice
>>> is almost impossible to provide using the current abuild/apk
>>> framework. I keep hearing of a Debian-style alternatives
>>> system, and supposedly it was specified somewhere, but I cannot
>>> find the specification nor an implementation. If I could read
>>> the specification I would be highly motivated to write an
>> This is correct and something that has been bothering us for a
>> while. A while back I wrote up a rough sketch of how such a system
>> would function in APK, which is likely what you are referring to.
>> It can be found here: https://txt.shiz.me/ZDNkNTY3MD.txt
> This seems like a decent start. I like how you can select all
> provided paths from a package or just a subset. This was actually
> requested by one of our early alpha testers.
> Would the relocations database have *every* file, or only those in
> conflict? I can see the argument either way.
APK already stores all files available to it in the installed-db.
Thusly, we would only need to store the redirections.
I think this should be a component of apk-tools.
>> I have no specific experience with apk-tools’s internals, but
>> would be open to looking into them to see what’s needed,
>> possibly/preferably with kaniini and fabled’s assistance and
>> insights as well.
> I have some experience with the internals of apk-tools, but not so
> much the database portion. Perhaps that is a task for this weekend :)
>> Something I’d like to see is file: dependencies (in the same vein
>> as so:, but for full file paths), but that’d require encoding the
>> entire file listing of a package in its `provides` metadata, which
>> I’m not sure we want due to APKINDEX file size bloat.
> I know that both Debian and Red Hat based systems have something like
> this stored in another index; `apt-file` and `yum provides`. The
> databases are somewhere around 100 MB compressed, so they obviously
> are not a part of the standard installation of apt/yum, but they are
> available to enable at any time for the users. I'm not sure if Alpine
> would want to do something similar. One method would be to have some
> sort of 'simplification' step when generating APKINDEX: only include
> file: from the master file database when a package references it. For
> would cause every `awk` provider to have a provides: line in APKINDEX
> for file:/usr/bin/awk. They wouldn't need to have a provides: for
> every file, only the ones that other packages reference.
This would severely bloat the APKINDEX. We should probably not do this.
>>> I started to try and make 'v:mta' but I'm very concerned about
>>> diverging so much from the Alpine aports tree. Also, apk doesn't
>>> support an automatic choice for a virtual if the user hasn't
>>> already installed one (something like replaces_priority but for
>>> virtuals would be good here imo). That means that when I *do*
>>> manage to get packages to depend on v:mta, the user now has to
>>> read through an 'unsatisfiable constraints' error and pick a
>>> package out of the list of providers.
>> I’m not sure what the best way to approach this would be in the
>> system sketch I laid out above.
> The above-linked specification doesn't resolve this in any way.
> That's fine because it doesn't need to. That can be a separate
> discussion / specification. (APK is already deficient in that regard,
> so it should be fixed independently of adding an alternatives system,
This could probably be solved by 'preference levels'.
The package with the highest preference level and lowest depgraph
solution cost would be selected.
>>> 3. It is very hard to know where to send some things. For
>>> example, the GCC APKBUILD does not function properly right now:
>>> it does not declare a makedepends on gcc-gnat, and the GCC
>>> configure process bails out when it does not find it because
>>> LANG_ADA is true whenever CBUILD == CHOST == CTARGET.
>> This would be a bug against aports in the bug tracker. Generally
>> most of us are somewhat busy, especially considering the time of
>> the year. Pinging specific people can work however — don’t take
>> our lack of response as lack of interest. :)
> I never took it as a lack of interest. I know that people are busy
> and have jobs and families and lives; for most of us, Alpine and
> related open-source projects are things we do because we like doing
> them, as a hobby. I will go ahead and file the bug in that section
> and keep that in mind if I come across any in the future.
>>> Additionally, changes made to abuild or apk-tools are currently
>>> being sent via GitHub pull requests. However, none of us in
>>> Adélie really want to use GitHub as it is a closed platform.
>>> The aports mailing list exists for aports, but where could we
>>> send abuild or apk-tools changes if we wanted an alternative to
>> These kind of changes should be sent to alpine-devel if you do not
>> wish to use GitHub.
> Duly noted. I would ask if there are any plans to install something
> like GitLab, Pagure, or Phabricator for Alpine at some point, but I
> don't really want to open such a can of worms :)
>>> 4. We have managed to make a split function 'openrc' that takes
>>> /etc/init.d and /etc/conf.d directories. It has
>>> install_if="$pkgname openrc" so it is transparent when you have
>>> OpenRC installed, and allows future migrations to a different
>>> init system. I don't know if this is of any interest to Alpine.
>> I’d like to see this, yes. It seems like a good addition in light
>> of the things discussed at FOSDEM with regards to init systems.
> I will send the patch to this list later today. It is very similar to
> the doc split function, so hopefully it is acceptable. If it is
> accepted, I will gladly forward on the packages that I have already
> split out -openrc for Adélie.
Once sent over, I see no reason why it wouldn't be accepted.
>>> 5. After being annoyed by bugs in the PowerPC build of GNU tar,
>>> we managed to swap out /usr/bin/tar for bsdtar provided by
>>> libarchive in abuild. It needed a patch to output the format
>>> apk expects by default, but otherwise it seems to work quite
>>> well. This may be of interest to those who want to do a GNU-free
>>> Alpine spin.
>> I’m not personally interested in bsdtar as I consider libarchive
>> fairly bloated, but if the patch is backwards-compatible with GNU
>> tar I would see no issue with including it at all.
> The patch is not for abuild. It is for libarchive itself. Renaming
> bsdtar to tar is sufficient for abuild to use it.
Lets go ahead and integrate this patch, I suppose.
Received on Tue Jul 25 2017 - 00:17:15 UTC