[aur-general] Package depends on 'provides' of another package
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I'm maintaining almost all packages related to VDR (tvdr.de) in the AUR. I also provide prebuild packages over here: https://c-reimer.de/vdr4arch/repos/vdr4arch/os/ The current pkgver of 'vdr' is 2.2.0 and it provides 'vdr-api=2.2.0', but vdr-api doesn't describe the actual vdr version. It describes the plugin API version and therefore isn't always equal to the pkgver. All plugins depend on 'vdr-api=2.2.0' (e.g. vdr-epgsearch) to trigger an update confict when an incompatible package is still installed or someone tries to install one. Unfortunately aurweb is unable to resolve vdr-api back to the actual vdr package. So either it's a bug in aurweb or my construct (vdr-plugin --> vdr-api - --> vdr) is way to complex an there's an easier approach. Any opinions? Thanks Christopher -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV6tQtAAoJENiLA36+LRnou5QIAJVGuVWdXuzllqyHqZBkoJNv ux7Q3cx2XLQuodMy/vXoQ4RmcxGGYekCOMp/fS/F016XQ5sIqGpT0s1kaprPD8Sh 7yS5NhzU0w6zUzsYrHocFFoW6IVoF9Lw+XgI2aTFJTHXAosiDTQKhdJHW3TgsBy4 U5Jq2Z5+UcEwQCZaUUgN3jHOWAiqgfwUYqSgJXnFWTBrR0qzmIy7bunPy2yvGXlP +dxIqEtjiiflIgFQ1RAxf8pyl8K50e8G0tDBINhZxeoQDW/s6zWWrQDsiWIAe3wH qkKusUAUsu/OqgZcEjN3nsR/k2cX3YEN+ML7zQdfLeFYnBL58QeDjjILUuTFRfI= =slWj -----END PGP SIGNATURE-----
On 05-09-15 13:38, Christopher Reimer wrote:
So either it's a bug in aurweb or my construct (vdr-plugin --> vdr-api - --> vdr) is way to complex an there's an easier approach.
Any opinions?
Thanks
Christopher
The easiest solution is to make vdr-api a virtual package, like java-environment. However, i'm 99% sure "real" virtual packages can only be created in official repos. For AUR you'll have to do with a dummy package . I think you should make vdr a split package with pkgbase= vdr and 2 package functions : package_vdr() and package_vdr-api() . vdr should depend on vdr-api . LW
On 05-09-15 15:06, LoneVVolf wrote:
vdr should depend on vdr-api .
LW
I think i got that wrong and it should be reversed : vdr-api needs to depend on vdr . LW
On 05.09.2015 18:14, LoneVVolf wrote:
I think i got that wrong and it should be reversed : vdr-api needs to depend on vdr .
According to "man 5 PKGBUILD" pkgver can't be changed for a split package. "All options and directives for the split packages default to the global values given in the PKGBUILD. Nevertheless, the following ones can be overridden within each split package’s packaging function: pkgdesc, arch, url, license, groups, depends, optdepends, provides, conflicts, replaces, backup, options, install, and changelog." What now? Christopher
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05.09.2015 15:06, LoneVVolf wrote:
The easiest solution is to make vdr-api a virtual package, like java-environment. However, i'm 99% sure "real" virtual packages can only be created in official repos.
Well. That's exactly what I'm doing right now. With my unofficial user repository it's working great. Pacman can handle it just like it does with java-environment. Unfortunately aurweb doesn't. The split package approach might work as a workaround but I don't really like where this is going. I'd like to something like this (https://www.archlinux.org/packages/extra/x86_64/eclipse-common) working in aurweb. It looks like aurweb isn't using provides and replaces information at all. Christopher -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV6xdAAAoJENiLA36+LRnoPlEH/1+7SDWzYO6nRfdYadelpVdE VtWwJgqApTUIOPG1msATG7ViwFfxhe0G7fciFn5C7mLmXCalHErZBzs4+m5bYE0e vDqFbTf/7LA0GXYt9qr9Ax/Bhrtgf4L/Rnx9GH8VA+nWja3YXC/6Ik62DyjgOCy3 KO9k68dxrXkIRoQsY3qJMFDDpfsfU2SKbewEJj2FuTDf6CActhEusMp6x/SpRqqJ 9KXRr5sDNyPm3r/2m+ICk3FWrK6aORpd1u42Q8Hc9s9PsEQYRiTigmm3E2mobTIS kv5IC0couBPryT+nyog+rtM3t2w7js12m+G7vQvxhNN/fJtYTglhJWAabAAr3Cs= =gfGU -----END PGP SIGNATURE-----
On 05/09, Christopher Reimer wrote:
Unfortunately aurweb is unable to resolve vdr-api back to the actual vdr package.
So either it's a bug in aurweb or my construct (vdr-plugin --> vdr-api - --> vdr) is way to complex an there's an easier approach.
It has nothing to do with being unable to. aurweb would be fully able to. It's that that's not how provides work. This behaviour is exactly like if you eg try doing a `pacman -Si` on the provide. Provides just provide another name for conflict resolution, and depending on a provide will likely never link to the package page of some random PKGBUILD that provides it because many things could provide the same thing and it's not a real package name. -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/
On 05.09.2015 20:15, Johannes Löthberg wrote:
On 05/09, Christopher Reimer wrote:
Unfortunately aurweb is unable to resolve vdr-api back to the actual vdr package.
So either it's a bug in aurweb or my construct (vdr-plugin --> vdr-api - --> vdr) is way to complex an there's an easier approach.
It has nothing to do with being unable to. aurweb would be fully able to. It's that that's not how provides work. This behaviour is exactly like if you eg try doing a `pacman -Si` on the provide. Provides just provide another name for conflict resolution, and depending on a provide will likely never link to the package page of some random PKGBUILD that provides it because many things could provide the same thing and it's not a real package name.
That makes sense. But I still don't know how to depend on vdr-api with a different pkgver than vdr itself. As this can happen, as it happened before. Thanks Christopher
On 05-09-15 21:22, Christopher Reimer wrote:
On 05.09.2015 20:15, Johannes Löthberg wrote:
On 05/09, Christopher Reimer wrote:
Unfortunately aurweb is unable to resolve vdr-api back to the actual vdr package.
So either it's a bug in aurweb or my construct (vdr-plugin --> vdr-api - --> vdr) is way to complex an there's an easier approach.
It has nothing to do with being unable to. aurweb would be fully able to. It's that that's not how provides work. This behaviour is exactly like if you eg try doing a `pacman -Si` on the provide. Provides just provide another name for conflict resolution, and depending on a provide will likely never link to the package page of some random PKGBUILD that provides it because many things could provide the same thing and it's not a real package name.
That makes sense. But I still don't know how to depend on vdr-api with a different pkgver than vdr itself.
As this can happen, as it happened before.
Thanks
Christopher
Ok, so a split package doesn't help because of the pkgver limitation. The workaround (a bit ugly) is then to create a standalone dummy package for vdr-api . You give it whatever value is needed as pkgver, and make it depend on the vdr package. LW
On 06.09.2015 13:55, LoneVVolf wrote:
Ok, so a split package doesn't help because of the pkgver limitation. The workaround (a bit ugly) is then to create a standalone dummy package for vdr-api . You give it whatever value is needed as pkgver, and make it depend on the vdr package.
LW
I don't really like it but it's working. Thanks Christopher
participants (3)
-
Christopher Reimer
-
Johannes Löthberg
-
LoneVVolf