X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com [209.85.220.171]) by lists.alpinelinux.org (Postfix) with ESMTP id BDBE45C4C64 for ; Tue, 25 Jul 2017 05:17:16 +0000 (GMT) Received: by mail-qk0-f171.google.com with SMTP id k2so24764089qkf.0 for ; Mon, 24 Jul 2017 22:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dereferenced-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dEHYUTCheAmmXbzEy/LNXRrpLMBwCiCi5uJa2hKDUog=; b=NbAbgf7E3vou+ODI/maF+qq1yX99K37Bbsl+HBOWvGlIMN2gplbxCzzV6vrPLv4wJ+ VKrthIZDjcHJ8PogxfWa4wsu423rHBEY3WSof54gowi7/qTXx2rbRVaO8z0YHPw28xWr O1K+tdwBzdv7LYkIuAEEnr3ZwGtbXbFbVAF0CuaROiOhxNhJwnN5iihwwJbjVqIXoSU+ VhLX1/6wAE2neaFuxAkA0mkyWPWgN7YHRWHpi6O/eZIOk59oz53e3AHvb9GoTQ/XYL5h cnKxmPNJxruqPGfGWvKkelFLxDW5I2nVJdSXghbCBhXO5fdxGqqfmsb+sKR/wJNCXtDd hpbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dEHYUTCheAmmXbzEy/LNXRrpLMBwCiCi5uJa2hKDUog=; b=aCMVtL2SCoqiiIp0dh/+Uxu5V3CF52ChB0Jq2tPTr7p3znxQgzEYrEnPalPN0m8joL 5SE6N2NBn1j7x726gjz02n0cslvD5Y8P1Sz7q76dZzrn6wWJnSxn9YtdOKLYbA1pmrKk pW1Nc9e1tdMoBoWV2xTpjkp3NkJTiuyWj5+ECumt8Z9h3UcTLCHO463OwvmxOi+ZM5b4 8MXB7Bt0TqAwnRkqq7mmvytoHoRkuMTkB12NtJm0VqySdiPAdvl41kx2ipRnI/x9z5hx RwqNKcLxb8AkawhdgHwATEDFNLAE3a8oQ6v1CTtsbq8bJkNT0aFakD6531fk6YnDSRQs QO8Q== X-Gm-Message-State: AIVw111fo+lHMOoI2VXt/1+mTwTB6wBVIt/sx5SavSiLXtLbUKjXpbJl S54Dg3s8jcIpzLjtWDA+fM+xfi102Q7w X-Received: by 10.55.119.131 with SMTP id s125mr20963050qkc.255.1500959836051; Mon, 24 Jul 2017 22:17:16 -0700 (PDT) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Received: by 10.200.46.10 with HTTP; Mon, 24 Jul 2017 22:17:15 -0700 (PDT) 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 Date: Tue, 25 Jul 2017 00:17:15 -0500 Message-ID: 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" Cc: Shiz , alpine-dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, On Mon, Jul 24, 2017 at 10:20 AM, A. Wilcox 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 ---