Mail archive

Re: [alpine-devel] Extend APKBUILD format with a variable to check framework versions

From: Natanael Copa <>
Date: Wed, 9 Jan 2019 09:53:32 +0100

On Tue, 08 Jan 2019 08:44:00 +0000
Oliver Smith <> wrote:

> Hey folks,

> 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.
> It was suggested to add a new variable instead, and since Alpine and
> Adélie 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.
> 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":
> relgroup="qt5"
> relgroup="kde-applications"
> 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.



> Regards,
> Oliver
> ---
> Unsubscribe:
> Help:
> ---

Received on Wed Jan 09 2019 - 09:53:32 UTC