Subject: =?UTF-8?Q?Re:_[alpine-devel]_Ad=c3=a9lie_on_Alpine=2c_two_months_la?=
 =?UTF-8?Q?ter?=
To: alpine-devel@lists.alpinelinux.org
References: <5975E0C0.1030008@adelielinux.org>
 <20170727114638.0917dbd2@ncopa-desktop.copa.dup.pw>
From: "A. Wilcox" <awilfox@adelielinux.org>
Organization: =?UTF-8?Q?Ad=c3=a9lie_Linux?=
Message-ID: <5979E814.2050301@adelielinux.org>
Date: Thu, 27 Jul 2017 08:18:12 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.0
Precedence: list
MIME-Version: 1.0
In-Reply-To: <20170727114638.0917dbd2@ncopa-desktop.copa.dup.pw>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

On 27/07/17 04:46, Natanael Copa wrote:
> On Mon, 24 Jul 2017 06:57:52 -0500 "A. Wilcox"=20
> <awilfox@adelielinux.org> wrote:
>> This is a sort of status update and wish list after near two=20
>> months of attempting to base Ad=E9lie on Alpine Linux.
>=20
> Thank you for sharing your experiences.


I am glad to be a part of a community where sharing is acceptable. :)


>> 1.  scripts/bootstrap.sh cannot "fake" cross.  Since Ad=E9lie uses=20
>> a slightly different GCC configuration from Alpine, I attempted=20
>> to run bootstrap.sh on x86_64, from my x86_64 system:
>>=20
>>=20
>> ERROR: unsatisfiable constraints: gcc-6.3.0-r4: conflicts:=20
>> gcc-x86_64-6.3.0-r4[so:libcilkrts.so.5=3D5.0.0]
>=20
> 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.


That might be an interesting way around it.  I will play with that
over this weekend and see how that works.


>> 2. The virtual system is pathetic.  One of the very core tenets=20
>> of Ad=E9lie is giving the user power through choice.  That choice=20
>> is almost impossible to provide using the current abuild/apk=20
>> 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=20
>> implementation.
>>=20
>> Red Hat has `alternatives`, Debian has `update-alternatives`, and
>> Gentoo has `eselect`.  The Alpine system desperately needs=20
>> something like this and I would love to contribute to such.
>=20
> I think something like update-alternatives or eselect makes sense.=20
> For example, you may want select which java implementation you=20
> should use as the "system" java.
>=20
> But I think we can divide it in 2 different cases:
>=20
> 1) symlinks (eg /usr/bin/lua -> /usr/bin/lua$version and=20
> /usr/bin/php -> /usr/bin/php$version). Selecting system java also=20
> goes here.
>=20
> 2) provides and dependencies in apk
>=20
> I am not convinced we should let apk handle the
> select/alternatives and mix that into the dependency calculation.


apk doesn't necessarily need to be the tool used to select the
alternative, but I'm not sure how packages that depend on something
like PHP or Java or Lua would work if apk wasn't somewhat aware.
Something like Gentoo's slots may work for some of them but I don't
think that's something that needs to be added to the APK format.
There needs to be a way to depend on "php" and have apk accept that
there are multiple PHP interpreters (such as a virtual or file path).


>> Consider a few different use cases:
>>=20
>> mta: any package that needs `sendmail` has to either hard-depend=20
>> on postfix, or disable mail services.  This is unacceptable in my
>> opinion.  Other distros let you select what package you want to
>> provide `sendmail`.
>=20
> It has been mentioned already, but I think for sendmail we want=20
> provides=3D/usr/sbin/sendmail in the different providers and the=20
> packages that needs it should do depends=3D/usr/sbin/sendmail. (we=20
> could do provides=3Dfile:/usr/sbin/sendmail too but i think that a=20
> leading '/' is enought to indicate that its a file)


So would that be manual (you put in the package provides=3D line that it
provides sendmail)?  That would probably be fine.


>> awk: mawk vs gawk vs busybox awk.  All have benefits and=20
>> drawbacks and the user should be able to choose which provides=20
>> /usr/bin/awk.
>=20
> 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=20
> packages needing it would be cumbersome. However, we could maybe
> do symlinks trick using alternatives/select functionality.


But then how would the dependency be satisfied?  If a package requires
'awk', then how would APK know that 'mawk' or 'busybox' satisfies it?

I have noticed that in general there is a deep expectation in aports
that BusyBox will always be present.  This really does not work too
well for Ad=E9lie, but I'm willing to take on the additional work of
fixing up aports if that work would be welcome.

If it wouldn't be welcome, the trees will likely diverge much more.
As I said in my opening email, Ad=E9lie wants the user to have the
maximum amount of freedom, and that includes the ability to choose
whether or not to use BusyBox.

[I will note here that "awk" in some form is required by POSIX; since
virtuals don't exist right now, 'mawk' is pulled in by adelie-base and
therefore the lack of explicit awk dependency does not break building
packages on Ad=E9lie.  Still, implicit dependencies are always a bad
thing IMO.]


>> shell: /bin/sh as busybox is of course default, but some users=20
>> may want bash or another shell.  I don't see any reason that=20
>> can't be supported.
>=20
> Same as awk.


My concern is for people to be able to choose what works for them.
Maybe they want to use sash+toybox+ubase or bash+coreutils or such,
instead of BusyBox.  All packages with shell scripts have an explicit
dependency to BusyBox[1] so that package effectively cannot be
uninstalled on an Alpine system.

If there was a 'shell' provider in the index, this could be solved
quite easily.

[1]: https://git.alpinelinux.org/cgit/abuild/tree/abuild.in#n897

Consider also a very very tiny run-from-RAM instance that only needed
an emergency shell and no other user interaction.  If sash could
replace busybox there could be a size benefit as well.  BusyBox is 900
kB installed and sash is 280 kB installed.


>> vi: busybox, vim, neovim, elvis, ...  There are almost a dozen=20
>> providers of `vi` in Debian and more than a dozen on Gentoo.  I=20
>> believe Alpine itself packages four of them.
>=20
> I don't know if I see the problem here. You can use the EDITOR env=20
> var to select any editor, even non-vi like nano.


Some programs do not obey EDITOR, but that is a good point.  Still,
most distros do allow you to choose the provider of `vi` and if
everything else is being fixed up I don't see any reason to ignore vi.


>> I started to try and make 'v:mta' but I'm very concerned about=20
>> 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=20
>> package out of the list of providers.
>=20
> I don't think 'v:mta' makes much sense (mta with tcp port 25 does=20
> not even need to run on local host), but I think=20
> provides=3D/usr/sbin/sendmail makes sense.


Yes, if such a format is allowed, that would be the ideal solution.


> 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.
>=20
> Maybe apk could, when the provides is unversioned and no provides=20
> installed, auto-select the provides with smallest size?


I feel like it could still output a message such as:

apk: selecting 'ssmtp' for provider of '/usr/sbin/sendmail'

That way the user knows what is happening and that they can select
another provider if they want.


> Then you atleast get something installed (for example ssmtp),
> which you can manually replace if you want.


Yes, that is the goal.


>> Additionally, changes made to abuild or apk-tools are currently=20
>> being sent via GitHub pull requests.  However, none of us in=20
>> 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=20
>> GitHub?
>=20
> It is mentioned before that you can use alpine-devel for that. I'd=20
> also suggest that you use --subject-prefix=3D"PATCH apk-tools" or=20
> "PATCH abuild" so its clear what project it belongs to.


Okay.  I will do that in the future.  Thanks for the guidance.


>> 4. We have managed to make a split function 'openrc' that takes=20
>> /etc/init.d and /etc/conf.d directories.  It has=20
>> install_if=3D"$pkgname openrc" so it is transparent when you have=20
>> OpenRC installed, and allows future migrations to a different=20
>> init system.  I don't know if this is of any interest to Alpine.
>=20
> I like this. Just make sure that the pkgname is versioned. eg
>=20
> install_if=3D"$pkgname-$pkgver-r$pkgrel openrc"
>=20
> 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!")


Yes, I did the same as the doc function which does the same :)


>> 5. After being annoyed by bugs in the PowerPC build of GNU tar,=20
>> we managed to swap out /usr/bin/tar for bsdtar provided by=20
>> 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.
>=20
> libarchive seems a bit bigger that gnu tar, otherwise I don't have
>  strong opinions. I would prefer to get the needed functionality=20
> added to busybox tar if possible.


That is understandable.  I took a look at the BusyBox tar code and it
was a bit over my head.  Perhaps someone else can add the requisite
functionality to it.  As far as I can tell, that would be:

* write pax format
* full xattr support

Everything else seems to be supported.

Best,
- --arw

>=20
> -nc
>=20

- --=20
A. Wilcox (awilfox)
Project Lead, Ad=E9lie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZeegTAAoJEMspy1GSK50UBl4P/11U24hRv++2Ye8bl/KRAw8G
bTZ6gNF5Olcr8QQPonEnCxooV7FhNp+toaDuyNV+a8vMWkRohf/Yv3iSoIForpX4
EQCqn4YM+1lR2MK98peqg7R7sMhRCK/QL1r2+lSoARQTWn0c8T/c3Umee9HsrTUJ
pDTISw93hL1p+2YTxtGy3SH3/Ck6bTPnuU3YnD1VIYtb9MQlurojuUeaEVapSvdw
Mipaf2stmbqvq4xz6tj5uW3Ke/Kv76syv4bt00ruhE9Yit3O9QxTRdjtP+zxkmJ7
clZd0YPoK4y3kKZX7+j1oRGpDWANrPUmwMfQjh3FhENuf3rhxHrCxfpWHFzM0TbA
FfsoEDuHLN7pGksTXLlC4FZh32863KFxZs+GCWmhudTLk8BQXcFEZbEeHplZB8rF
FNGYAHotPU4L4+sl5Et4v/u1U87A3fC/bdsNagDhr+SykldhH7MA0qrOMtjUJsJg
YfHR8jD4Ef09BvHsiXUt9ocHTWpaAy6fG2lD5Zd7j+rihVwSV1/Ze8/uQGgEI098
q3dYva9G8dIj3tzE9/bJX/J9QvAnxVXNJ7WiU7qxYBcq7ewF+Zdxxq9jtIl9Ohdb
Xsx1RO2No+LJED9nsydEGgWJ6kf44dgcQ+5tGc6HwfKIHTTmyawk4NAso92NYOY9
QSVE4RF1RRvL1AhBtann
=3DBBov
-----END PGP SIGNATURE-----


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---