Subpackage versioning
The following discussion from !28195 (merged) should be addressed:
-
@jirutka started a discussion: (+14 comments) pkgver
should not be redefined for subpackages. I tried that a few years ago in some aports and it didn’t work well with the build servers (I don’t remember details). However, maybe this is a good time to open a discussion about this, because this is a quite unfortunate limitation and I’d like to overcome it.
dotnet packages require custom pkgver within subpackages, as SDK and Runtime have different versioning schemes. This is not currently supported by buildrepo or abuild as they source only global pkgver to check if there should be a rebuild of packages, or whether old packages should be purged. I implemented a mitigation from within my aports that create a symbolic link between where the APK is expected to be by abuild and buildrepo, and where it actually is. This works for most use-cases that I could test for, except for buildrepo's purging functionality. As buildrepo purges every APK that doesn't match (name or pkg.pkgname).."-"..pkg.pkgver.."-r"..pkg.pkgrel..".apk"
, this means it deletes any subpackage with custom pkgver.
The mitigation is as follows:
scan_symlink_targets() {
local name="$1" dir="$2"
local ver=$(pkginfo_val pkgver "$dir"/.PKGINFO)
local subpkgarch=$(pkginfo_val arch "$dir"/.PKGINFO)
[ -d "$REPODEST"/${repo:?}/${subpkgarch/noarch/$CARCH} ] || mkdir -p "$REPODEST"/$repo/${subpkgarch/noarch/$CARCH}
[ "$ver" = "$pkgver-r$pkgrel" ] || ln -sf "$REPODEST"/$repo/${subpkgarch/noarch/$CARCH}/$name-$ver.apk "$REPODEST"/$repo/${subpkgarch/noarch/$CARCH}/$name-$pkgver-r$pkgrel.apk
}
Problematic functions
Through my attempts at figuring out a mitigation, I identified the following problematic functions
abuild
-
scan_symlink_targets
: when it detects symlink dependencies between subpkgs sets a hard dependency to that specific version of subpackage. Above mitigation neutralizes scan_symlink_targets, leaving the maintainer to set those dependencies explicitely -
apk_up2date
/abuildindex_up2date
:root cause of subpkg issues in abuild. Both functions define expected path as"$dir"/$subpkgname-$pkgver-r$pkgrel.apk
. Since these are defined from within a for loop for each package,$pkgver
should rather be$subpkgver
, but no logics are in place to do so. -
subpkg_set
: defines above$pkgver
variable. Logics for$subpkgver
would be implemented here.
lua-aports
-
db:each_need_build
/ purge logics (buildrepo
): former relies onpkg.apk_file_exists
which checks if there's a readable file at output ofget_apk_file_path
, which relies onget_apk_file_name
. Latter also relies onget_apk_file_name
-
get_apk_file_name
(buildrepo/pkg.lua
): root function of the above functions, definesapk_file_name
as(name or pkg.pkgname).."-"..pkg.pkgver.."-r"..pkg.pkgrel..".apk"
.pkg.pkgver
is presumable sourced from aport's global pkgver rather than APKINDEX. Ifget_apk_file_name
sourced pkg.pkgver from subpkgver, this would likely fix the issues with buildrepo. This function is thus a root-case for issues relating to subpkg versioning.
Implementation proposal
aports
Similar to :arch implementation within subpackages array, this would probably be a similar strategy to define pkgver for subpackages. Although in all honesty the current :arch implementation is not scalable, there isn't room for more arguments. Something better would be defining custom variables as $pkgname-$subpackage_var=
, thus allowing more actual sourcing of variables. I'd ideally like to see sourcing of variables from within subpackage functions, but that would make it hard for sourcing by buildrepo and aports. Thus, subpkg_set
could set $subpkgver
.
Buildrepo
Above implementation where custom variables are defined as $pkgname-$subpackage_var=
along with other variables would make for easy sourcing by buildrepo in get_apk_file_name