Hi,

I am planing to build/maintain a small set of packages locally,
(after some experimental changes),
below is a versioning method I was thinking to do,

For packages that are already in aports,
a. have same version as in aports, so as to keep in track/update with 
upstream alpine-aports version.
b. add some sort to policy marker in version, eg. package
    abc-xyz-1.2.3-r0-vkr

Entry in APKBUILD would look like:
-------------
pkgname=abc-xyz
pkgver=1.2.3
pkgrel=0
brand=vkr
-------------

Here "brand" value is a keyword for apk-tools to sort and handle both 
original package and custom package.

Make an entry in /etc/conf.d/apk(default), /etc/apk/policy

eg, policy configs

[brand]
vkr >= ""
vkr >= pmo
deb <= alp
sel >= ""

so, based on brand apk-tool should be able sort and install the package 
if both version is same.

Any guide and suggestion on other approaches would be helpful.

-- 
Regards,
V.Krishn

On Mon Oct 5, 2026 at 7:29 PM CEST, V.Krishn wrote:
>
> Hi,
>
> I am planing to build/maintain a small set of packages locally,
> (after some experimental changes),
> below is a versioning method I was thinking to do,
>
> For packages that are already in aports,
> a. have same version as in aports, so as to keep in track/update with 
> upstream alpine-aports version.
> b. add some sort to policy marker in version, eg. package
>     abc-xyz-1.2.3-r0-vkr
>
> Entry in APKBUILD would look like:
> -------------
> pkgname=abc-xyz
> pkgver=1.2.3
> pkgrel=0
> brand=vkr
> -------------
>
> Here "brand" value is a keyword for apk-tools to sort and handle both 
> original package and custom package.
>
> Make an entry in /etc/conf.d/apk(default), /etc/apk/policy
>
> eg, policy configs
>
> [brand]
> vkr >= ""
> vkr >= pmo
> deb <= alp
> sel >= ""
>
> so, based on brand apk-tool should be able sort and install the package 
> if both version is same.
>
> Any guide and suggestion on other approaches would be helpful.


For maintaing local packages in my experience the easiest option is to
package it under a different name and have provides that meet
dependencies when necessary. Sometimes people also use very-hight version
numbers.

In many cases tagged repositories can also help with managing local
packages as one wants.

On 10/5/26 17:06, Sertonix wrote:
> On Mon Oct 5, 2026 at 7:29 PM CEST, V.Krishn wrote:
>>
>> Hi,
>>
>> I am planing to build/maintain a small set of packages locally,
>> (after some experimental changes),
>> below is a versioning method I was thinking to do,
>>
>> For packages that are already in aports,
>> a. have same version as in aports, so as to keep in track/update with
>> upstream alpine-aports version.
>> b. add some sort to policy marker in version, eg. package
>>      abc-xyz-1.2.3-r0-vkr
>>
>> Entry in APKBUILD would look like:
>> -------------
>> pkgname=abc-xyz
>> pkgver=1.2.3
>> pkgrel=0
>> brand=vkr
>> -------------
>>
>> Here "brand" value is a keyword for apk-tools to sort and handle both
>> original package and custom package.
>>
>> Make an entry in /etc/conf.d/apk(default), /etc/apk/policy
>>
>> eg, policy configs
>>
>> [brand]
>> vkr >= ""
>> vkr >= pmo
>> deb <= alp
>> sel >= ""
>>
>> so, based on brand apk-tool should be able sort and install the package
>> if both version is same.
>>
>> Any guide and suggestion on other approaches would be helpful.
> 
> 
> For maintaing local packages in my experience the easiest option is to
> package it under a different name and have provides that meet
> dependencies when necessary. Sometimes people also use very-hight version
> numbers.
> 
> In many cases tagged repositories can also help with managing local
> packages as one wants.

I am trying to avoid different name and tagging or pinning explicitly,
but may have to resort to it :(.

Another reason apart from easy maintenance of aports, would be, then I 
can change the policy from eg.

[brand]
pmo >= ""

[brand]
pmo >= ""
nur >= pmo

and switch to different a brand, without lots of changes.


-- 
Regards,
V.Krishn

On Mon, 5 Oct 2026, at 19:29, V.Krishn wrote:
> Hi,
>
> I am planing to build/maintain a small set of packages locally,
> (after some experimental changes),
> below is a versioning method I was thinking to do,
>
> For packages that are already in aports,
> a. have same version as in aports, so as to keep in track/update with 
> upstream alpine-aports version.
> b. add some sort to policy marker in version, eg. package
>     abc-xyz-1.2.3-r0-vkr
>
> Entry in APKBUILD would look like:
> -------------
> pkgname=abc-xyz
> pkgver=1.2.3
> pkgrel=0
> brand=vkr
> -------------

abuild has no awareness of this "brand" field. It won't
be included in the package, nor in the index. apk is
oblivious to this value being set here.

-- 
Hugo

On 10/5/26 17:35, Hugo Osvaldo Barrera wrote:
> 
> 
> On Mon, 5 Oct 2026, at 19:29, V.Krishn wrote:
>> Hi,
>>
>> I am planing to build/maintain a small set of packages locally,
>> (after some experimental changes),
>> below is a versioning method I was thinking to do,
>>
>> For packages that are already in aports,
>> a. have same version as in aports, so as to keep in track/update with
>> upstream alpine-aports version.
>> b. add some sort to policy marker in version, eg. package
>>      abc-xyz-1.2.3-r0-vkr
>>
>> Entry in APKBUILD would look like:
>> -------------
>> pkgname=abc-xyz
>> pkgver=1.2.3
>> pkgrel=0
>> brand=vkr
>> -------------
> 
> abuild has no awareness of this "brand" field. It won't
> be included in the package, nor in the index. apk is
> oblivious to this value being set here.
> 

I think I would do a feature request for it in gitlab, but wait for some 
comments to reason out its usability.

-- 
Regards,
V.Krishn