Date: Wed, 9 Jan 2019 09:53:32 +0100
From: Natanael Copa <ncopa@alpinelinux.org>
To: Oliver Smith <ollieparanoid@bitmessage.ch>
Cc: alpine-dev <alpine-devel@lists.alpinelinux.org>
Subject: Re: [alpine-devel] Extend APKBUILD format with a variable to check
 framework versions
Message-ID: <20190109095332.410fd5f1@ncopa-desktop.copa.dup.pw>
In-Reply-To: <c471c82c-f128-58ba-f903-1e25ad5c857d@bitmessage.ch>
References: <c471c82c-f128-58ba-f903-1e25ad5c857d@bitmessage.ch>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, 08 Jan 2019 08:44:00 +0000
Oliver Smith <ollieparanoid@bitmessage.ch> wrote:

> Hey folks,

Hi!
=20
> various frameworks, such as Qt (available in Alpine), KDE Plasma, KDE
> Framework have a lot of components that get released together and
> therefore must have the same pkgver. In postmarketOS we have a CI check
> in place, that makes sure, that the version matches for all these
> components. Right now we are categorizing the frameworks by their URL,
> but that is of course not the purpose of the URL variable.
>=20
> It was suggested to add a new variable instead, and since Alpine and
> Ad=E9lie would probably benefit from such a check and variable as well, I
> wonder if it makes sense to make this variable official and add it to
> the APKBUILD reference in Alpine's wiki. I could add a simple shell
> script that checks the package versions based on that variable in
> Alpine's aports.git to be used by Travis.
>=20
> I would like to keep "framework" out of the name, as this may also be
> the case for non-frameworks, such as the KDE Applications, which are
> also released together.

There are various other packages that would befit from this, for example:

- llvm/clang/compiler-rt
- kernel and 3rd party modules
- poppler/poppler-qt4
- python/python-tkinter
- wpa_supplicant/wpa_gui
- shorewall/shorewall-core/shorewall6
- audacious/audacious-plugins

Some of those are like qt5 a bigger project splitted up in minor
pieces, and some are built from same source but needs to be built from
different APKBUILDs to avoid circular dependencies.

> One idea for the name would be "relgroup", as in "release group":
>=20
>   relgroup=3D"qt5"
>   relgroup=3D"kde-applications"
>=20
> What do you think?

relgroup sounds good.

I am not sure I would like to implement this in abuild though. It would
be an external tool (which may be called from abuild if configured to do
so). I think it would be good to perform the check and error out on
mismatches from a git push hook.

I'd like to continue discuss the implementation details after v3.9
release, which is top prio right now.

Thanks!

-nc

>=20
> Regards,
> Oliver
>=20
>=20
>=20
> ---
> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> Help:         alpine-devel+help@lists.alpinelinux.org
> ---
>=20



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---