X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mx1.tetrasec.net (mx1.tetrasec.net [74.117.190.25]) by lists.alpinelinux.org (Postfix) with ESMTP id 5AF535C5545 for ; Fri, 30 Jun 2017 06:15:02 +0000 (GMT) Received: from mx1.tetrasec.net (mail.local [127.0.0.1]) by mx1.tetrasec.net (Postfix) with ESMTP id 2D1A79E22D0; Fri, 30 Jun 2017 06:15:02 +0000 (GMT) Received: from ncopa-desktop.copa.dup.pw (15.63.200.37.customer.cdi.no [37.200.63.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: n@tanael.org) by mx1.tetrasec.net (Postfix) with ESMTPSA id 457E99E20AC; Fri, 30 Jun 2017 06:15:00 +0000 (GMT) Date: Fri, 30 Jun 2017 08:14:54 +0200 From: Natanael Copa To: Jakub Jirutka Cc: Tmp File , alpine-devel@lists.alpinelinux.org Subject: Re: [alpine-devel] Script to parse APKBUILDS and output table of arch support Message-ID: <20170630081454.019fa6e4@ncopa-desktop.copa.dup.pw> In-Reply-To: <315008DD-D5EB-4369-8A80-F46F10DC528A@jirutka.cz> References: <315008DD-D5EB-4369-8A80-F46F10DC528A@jirutka.cz> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-alpine-linux-musl) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, 20 Jun 2017 18:06:28 +0200 Jakub Jirutka wrote: > Hi, >=20 > seding APKBUILDs is not a very good approach how to gather this > information. That said, it can quite work in this case, for *arch*, > because this is rarely (if ever) dynamic (e.g. adding archs based on > some conditions) or variously formatted, but not for all variables. >=20 I agree. The way to parse the APKBUILDs is to execute them. > We already have library for sort of programmatic reading of > APKBUILDs: https://github.com/alpinelinux/lua-aports > . It basically just > evaluates every APKBUILD, prints and parsers the selected variables. > This is used e.g. in pkgs.a.o. I started on a aports-cache project while on the plane. Its a small C program (soon library) that parses all the APKBUILDs and writes a yaml output file. It compares the timepstams on the APKBUILDs and update the cache if needed. I haven't decided if we want keep the yaml format or if we should use toml or json for this. I think the way forward is to have a common library that parses the APKBUILDs and let the tools use the cache where all shell variables are expanded. The idea is to make a lua-aports-cache binding and let lua-aports use this. We could also make bindings to python, ruby etc. > I agree that such reports would be useful for maintainers for > recently added platforms. However, there are much more reports that > would be useful, so it*d be better to separate data and presentation. Agree. When thinking of it, we might need a separate json/yaml/toml for each arch. There might be conditionals, for example different set of subpackages for each arch. > I mean, create a simple RESTful API for aports or just some JSON > export, so anyone can make whatever report needs, without parsing > APKBUILDs over and over again. This is yet another thing on my very > long TODO list* Hm, maybe this week. It*s pity that we are so > dislocated over the planet, some local hackathons may be very > productive for such tasks. :) -nc > Jakub >=20 > > On 20. Jun 2017, at 16:21, Tmp File wrote: > >=20 > > Good morning Alpiners. > > =20 > > I wrote a shell script that reads all APKBUILDS on a repository, parses= the arch=3D setting, and output a csv table with detailed information abou= t which package is supported by which architecture. > > =20 > > https://github.com/tmpfile/table > > =20 > > It outputs a complete table and also a table of only packages that aren= 't supported for all archs. > > =20 > > Here's the final result: https://github.com/tmpfile/table/blob/master/m= issing_support_table.csv > > =20 > > I think this can be of great help to arch maintainers so they can know = with more ease which packages they must work on. > > =20 > > My goal sharing this work is that someone implements it as a cron job (= for example) on alpinelinux.org/table.html or some other address. > > =20 > > In the testing I parsed only main/ but it should also work for communit= y/ and /testing. > > =20 > > Let me know your opinion. > > =20 > > tmpfile > > =20 > > --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: a= lpine-devel+help@lists.alpinelinux.org --- =20 >=20 --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---