Date: Sat, 8 Feb 2020 18:37:06 -0800
From: Clayton Craft <clayton@craftyguy.net>
To: Timo Teras <timo.teras@iki.fi>
Cc: ~alpine/apk-tools@lists.alpinelinux.org
Subject: Re: supporting multiple versions of same package in single repo
Message-ID: <20200209023706.rizdc3333ljjjrie@computer.craftyguy.net>
References: <20200203222821.wty53efr5u2sx3gk@computer.craftyguy.net>
 <20200204110646.2d9f80b4@vostro>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="qtmh3rhpolpiuelx"
Content-Disposition: inline
In-Reply-To: <20200204110646.2d9f80b4@vostro>


--qtmh3rhpolpiuelx
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline

On Tue, Feb 04, 2020 at 11:06:52AM +0200, Timo Teras wrote:
>Hi
>
>On Mon, 3 Feb 2020 14:28:21 -0800
>Clayton Craft <clayton@craftyguy.net> wrote:
>
>> In postmarketOS we are attempting to have 2 versions of mesa: 'mesa'
>> (from upstream Alpine), and 'mesa-git' (tracks upstream mesa master
>> branch).  The goal is to have both packages + their respective
>> subpackages provide system mesa for an install. Only one (mesa or
>> mesa-git) is expected to be installed on a single system at one time.
>> When a user installs 'mesa-git', and then (for example) installs a
>> package which depends on 'mesa-dev', the idea is that 'mesa-git-dev'
>> would be installed instead of 'mesa-dev'. We want 2 versions of mesa
>> since some devices pmos supports require a newer mesa than what is
>> currently in the latest mesa stable branch.
>>
>> We are having a very hard time coming up with a mesa-git APKBUILD
>> that can do this. In IRC, it was mentioned that we could use a
>> virtual package, and rename 'mesa' to something else, and handle
>> installing either of the 2 packages in the virtual package. This
>> would probably work (?) but is less than ideal since we'd have to
>> keep the renamed mesa package in sync with upstream Alpine's mesa
>> package.
>>
>> Arch Linux seems to be able to handle this scenario without issue,
>> AUR has a mesa-git package which results in mesa-git-* subpackages
>> being installed at the right time (when something depends on
>> mesa-dev, etc). Is apk/APKBUILD capable of supporting this, or does
>> anyone have any advice/suggestions on how this goal could be achieved?
>
>Interesting setup. I wonder if in Arch it is a feature where a global
>substitution rule diverts mesa-dev to mesa-git-dev or similar.
>
>Using purely apk dependencies, you could try the following:
>
>1. mesa-git-dev
>  provides="mesa-dev"
>  provider_priority=1
>
>  The provides tells it's good for 'mesa-dev'. Since there's no provided
>  version specified it's not good for automatic install; the
>  provider_priority=1 makes that happen.
>
>  One caveat is at least that if someone depends e.g "mesa-dev>19.0", it
>  would not get satisfied with the mesa-git-dev.
>
>  OR
>
>  provides="mesa-dev=19.2"
>
>  To make the git act as if it was this version. You probably then want
>  a smaller version than what the real mesa is so that the mesa-git-dev
>  does not get preferred always.

Hmm, I think either option could cause issues. The first option is an issue
because there do seem to be some packages that depend on 'mesa-dev>=19.3'. With
the second option, some packages would pull in mesa-dev if they depended on a
version greater than what is set in mesa-git-dev's "provides".

When apk is faced with two packages that 'provide' a virtual package (e.g.
'mesa' vs 'mesa-git'), and 'provider_priority' is not set in either one, what
breaks the tie? Is it the one with the higher version (assuming one is specified
in the 'provides=')?

>
>2. mesa-git
>  depends="!mesa"

I was attempting to test this, but apk complains:
(2363538) [18:28:58] ERROR: Package '!mesa': Could not find aport, and could not
find this package in any APKINDEX!

>
>  To make sure that depending on 'mesa-dev' does not prefer the real
>  package and try to pull in it's dependencies.
>
>Interesting to hear if the above works.
>
>Timo

--qtmh3rhpolpiuelx
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEwg7UY5aqqncO8SLrI6MNptQGs1UFAl4/cFIACgkQI6MNptQG
s1UFGg/9E1QWUJIH60VZRPEH/SwvSYkG7smpGUviNbawo8GG9ebW7lXdETWX4xuG
KirPMzWKD3LesoSQhZbRw265HCVEyP9MRI0pqx/i7lSokY0Pgkbabqc7hKuzXdyb
NNFjoaavztN2aI+CCAfeLOnswN0MsExp3cM84QWf+2Jdn4aUXx7hDiBu2EIb5+ic
opBuRsOqIPbV04zCcIh6jrMnsbSroI2Ueg97tSk+1cUZ6r7DXuzQooV9VtTKBq70
msL7uCMdHTeE6HK19T109z8+TpWJ0XF+wScLzeuDYRM+y2SIlp2LC96q6bZ7F7sV
Mbk+3qwTMz6r0YI65q1b7b7X7CWiUE1itxfivzUbZkyVsH9z91dhkxJI/9NZ8Jbm
MZg/CIY9BNEPGv+RvhlC66F9G7tTOK6wG496fOV+0JkYQXSUhOZnQEC0wCtsF5zc
QOUkTof89OoPMqdMKBjeke/i0UW047sUCf7md3WJL1hW0pbJQwtfrIu11lFkjJIF
kmqlA7DDcAaueQOz5sU649PmPTinQpSLdIm5JmXMC2zswynYrNnswABZYsgy3CIX
DXvaplxlEA7/9pwzT7NlvnGUKzlVpNphlRBq1kDgpA9xr4O+KXbS1Nu/ynQn2EbX
uwA1M8U/o2oZLkECOjP6LNdJxhNfdvGXEyEh03u3vmffADc6vuE=
=t2RM
-----END PGP SIGNATURE-----

--qtmh3rhpolpiuelx--