Precedence: list
MIME-Version: 1.0
In-Reply-To: <59761031.6000605@adelielinux.org>
References: <5975E0C0.1030008@adelielinux.org> <57A1A151-0352-40DA-BC91-52980CEE99C3@shiz.me>
 <59761031.6000605@adelielinux.org>
From: William Pitcock <nenolod@dereferenced.org>
Date: Tue, 25 Jul 2017 00:17:15 -0500
Message-ID: <CA+T2pCHrDjTXmqAhq1FnDzTk-nGvakh06y=ovVUYW0_FM=hfVw@mail.gmail.com>
Subject: =?UTF-8?Q?Re=3A_=5Balpine=2Ddevel=5D_Ad=C3=A9lie_on_Alpine=2C_two_months_lat?=
	=?UTF-8?Q?er?=
To: "A. Wilcox" <awilfox@adelielinux.org>
Cc: Shiz <hi@shiz.me>, alpine-dev <alpine-devel@lists.alpinelinux.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello,

On Mon, Jul 24, 2017 at 10:20 AM, A. Wilcox <awilfox@adelielinux.org> wrote=
:
>>> 2. The virtual system is pathetic.  One of the very core tenets
>>> of Ad=C3=A9lie 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
>>> implementation.
>>
>> 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=E2=80=99s internals, but
>> would be open to looking into them to see what=E2=80=99s needed,
>> possibly/preferably with kaniini and fabled=E2=80=99s 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=E2=80=99d like to see is file: dependencies (in the same vei=
n
>> as so:, but for full file paths), but that=E2=80=99d require encoding th=
e
>> entire file listing of a package in its `provides` metadata, which
>> I=E2=80=99m 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
> example:
>
> depends=3D"file:/usr/bin/awk"
>
> 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=E2=80=99m 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,
> IMO.)

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 =3D=3D CHOST =3D=3D 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 =E2=80=94 don=E2=80=
=99t 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=C3=A9lie 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
>>> GitHub?
>>
>> 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=3D"$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=E2=80=99d like to see this, yes. It seems like a good addition in ligh=
t
>> 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=C3=A9lie.

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=E2=80=99m 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.

William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---