Date: Thu, 27 Jul 2017 11:46:38 +0200
From: Natanael Copa <ncopa@alpinelinux.org>
To: "A. Wilcox" <awilfox@adelielinux.org>
Cc: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] =?ISO-8859-1?B?QWTpbGll?= on Alpine, two months
 later
Message-ID: <20170727114638.0917dbd2@ncopa-desktop.copa.dup.pw>
In-Reply-To: <5975E0C0.1030008@adelielinux.org>
References: <5975E0C0.1030008@adelielinux.org>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, 24 Jul 2017 06:57:52 -0500
"A. Wilcox" <awilfox@adelielinux.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>=20
> Hi there Alpinists,
>=20
> This is a sort of status update and wish list after near two months of
> attempting to base Ad=E9lie on Alpine Linux.

Thank you for sharing your experiences.

>=20
> 1.  scripts/bootstrap.sh cannot "fake" cross.  Since Ad=E9lie uses a
> slightly different GCC configuration from Alpine, I attempted to run
> bootstrap.sh on x86_64, from my x86_64 system:
>=20
>=20
> ERROR: unsatisfiable constraints:
>   gcc-6.3.0-r4:
>     conflicts: gcc-x86_64-6.3.0-r4[so:libcilkrts.so.5=3D5.0.0]

I wonder if it would make sense to add provides=3D"$pkgname-$arch" to
gcc. That way "gcc-x86_64" would be provided from "gcc" on x86_64.

> 2. The virtual system is pathetic.  One of the very core tenets of
> Ad=E9lie 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.
>=20
> Red Hat has `alternatives`, Debian has `update-alternatives`, and
> Gentoo has `eselect`.  The Alpine system desperately needs something
> like this and I would love to contribute to such.

I think something like update-alternatives or eselect makes sense. For
example, you may want select which java implementation you should use
as the "system" java.

But I think we can divide it in 2 different cases:

1) symlinks (eg /usr/bin/lua -> /usr/bin/lua$version and /usr/bin/php
   -> /usr/bin/php$version). Selecting system java also goes here.

2) provides and dependencies in apk

I am not convinced we should let apk handle the select/alternatives and
mix that into the dependency calculation.


> Consider a few different use cases:
>=20
> mta: any package that needs `sendmail` has to either hard-depend on
> postfix, or disable mail services.  This is unacceptable in my
> opinion.  Other distros let you select what package you want to
> provide `sendmail`.


It has been mentioned already, but I think for sendmail we want
provides=3D/usr/sbin/sendmail in the different providers and the packages
that needs it should do depends=3D/usr/sbin/sendmail. (we could do
provides=3Dfile:/usr/sbin/sendmail too but i think that a leading '/'
is enought to indicate that its a file)
=20
> awk: mawk vs gawk vs busybox awk.  All have benefits and drawbacks and
> the user should be able to choose which provides /usr/bin/awk.

Also mentioned before that awk is a part of the base system and is
expected to be there. So adding depends=3D/usr/bin/awk to all packages
needing it would be cumbersome. However, we could maybe do symlinks
trick using alternatives/select functionality.
=20
> shell: /bin/sh as busybox is of course default, but some users may
> want bash or another shell.  I don't see any reason that can't be
> supported.

Same as awk.

> vi: busybox, vim, neovim, elvis, ...  There are almost a dozen
> providers of `vi` in Debian and more than a dozen on Gentoo.  I
> believe Alpine itself packages four of them.

I don't know if I see the problem here. You can use the EDITOR env var
to select any editor, even non-vi like nano.

> 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 don't think 'v:mta' makes much sense (mta with tcp port 25 does not
even need to run on local host), but I think provides=3D/usr/sbin/sendmail
makes sense.

Currently you can have unversioned provides and have them installed in
parallel, but then apk will not autoselect anything for you or you can
have the provides versioned and apk will select one for you. But then
you will not be able to have both installed at the same time.

Maybe apk could, when the provides is unversioned and no provides
installed, auto-select the provides with smallest size?

Then you atleast get something installed (for example ssmtp), which you
can manually replace if you want.

=20
> 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.  I am not 100% confident in my ability to ed=
it
> the APKBUILD for GCC considering how finicky it is, so I would like
> help.  I posted on the IRC channel but I mainly only have the weekends
> to work on Ad=E9lie, and most of the channel is away on weekends.  This
> really isn't a distro topic, so it doesn't belong on alpine-devel from
> what I have been able to gather about this list.  The aports list
> seems to be for patches only, from what I have gathered about that
> list.  Maybe this belongs on the bug tracker, but there really isn't a
> bug category for build failures that I could find.
>=20
> Additionally, changes made to abuild or apk-tools are currently being
> sent via GitHub pull requests.  However, none of us in Ad=E9lie 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?

It is mentioned before that you can use alpine-devel for that. I'd also
suggest that you use --subject-prefix=3D"PATCH apk-tools" or "PATCH
abuild" so its clear what project it belongs to.

> 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 like this. Just make sure that the pkgname is versioned. eg

  install_if=3D"$pkgname-$pkgver-r$pkgrel openrc"

Otherwise interesting things will happen if you have older versions of
$pkgname in you local build repository. (older versions will see it
and, "hey openrc and $pkgname is installed. i want be installed too!")

> 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.

libarchive seems a bit bigger that gnu tar, otherwise I don't have
strong opinions. I would prefer to get the needed functionality added
to busybox tar if possible.

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---