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?

-Clayton

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.

2. mesa-git
  depends="!mesa"

  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

On 04/02/2020 03:06, 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.
> 
> 2. mesa-git
>   depends="!mesa"
> 
>   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
> 

We use something like the first one for our kernel build.  The package
name is easy-kernel-5.4.5-mc0 (for instance), which
provides="easy-kernel=5.4.5-r0".

https://code.foxkit.us/adelie/packages/blob/master/system/easy-kernel/APKBUILD

It works okay, and you could probably use depends= on the subpkgs to
ensure that they're all consistent.

We still sort of wish that it was possible to side-by-side install
packages that provides="$pkgname" with different versions, so people
could have more than one kernel version installed if the installed files
don't conflict (which wouldn't with kernels).  But I suppose that is
unrelated to this topic.


Best,
--arw


-- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org

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

On Sat, 8 Feb 2020 18:37:06 -0800
Clayton Craft <clayton@craftyguy.net> wrote:

> On Tue, Feb 04, 2020 at 11:06:52AM +0200, Timo Teras wrote:
> >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.

If you are using separate repositories of which only one get's picked
up (or even if just the mesa-git providing repository is additional),
you can just have each mesa-git-* package provides="mesa-*=$pkgver"
where $pkgver should compare to something grater than the regular mesa.

Timo