On 3/29/23 15:43, Anton Hvornum wrote:
On 3/22/23 22:34, Anton Hvornum wrote: Furthermore it lacks proper provides/conflicts declaration on the none -git named archinstall package itself (both provide/conflict the same meta declaration, but in terms of correctness it should always conflict on the none git pkgname). I assumed (incorrectly?) that since both have 'provides' that point to 'python-archinstall' they detect the conflict automatically. Would 'conflicts=(python-archinstall-git)' be appropriate in the non -git
On 3/26/23 13:43, Levente Polyak wrote: package or should it be 'conflicts=(archinstall-git)' as the package is called 'archinstall-git' not 'python-archinstall-git'?
Theoretically the assumption about `python-archinstall` is correct, but let me shortly explain why it still matters: Such provides are just additional metadata, often also just used to replace a former package name. Such can a lot easier change or vanish. Another reason: using python2 here just to have a simple visualization of the issue (could be anything i reality): `python-archinstall` correctly states it provides a python library part of archinstall. Imagine a scenario where there would by a python2 or whatever version then declaring `python-archinstall` would be wrong as that's not what it provides or conflicts, it conflicts on `usr/bin/archinstall`. A good practice that just solves all the issues is to simply declare provides/conflicts on the canonical none-special variant: In this case `archinstall`. To the second part: I do see cases where the canonical none-special variant does conflict on special purpose variants. That should not be done. It's the responsibility of the special purpose variants to conflict on the canonical variant. Let me also picture this really quickly: Imagine someone would be adding new special purpose variants, that could happen to any arbitrary point in time. If this rule is not followed, that would mean the canonical variant needs to be updated whenever a new special purpose variant materializes. This would not be much fun :) On the other hand, if the rule is followed that special purpose variants must declare its conflict against the canonical variant, then automatically any case is covered at whatever time a new variant materializes. So the take on this should be to always follow those 2 simple rules to be happy and safe 😺: - always (at least additionally) conflict on the actual canonical package in the special purpose variants - never conflict on special purpose variants in the canonical variant package. Notify them instead and let that be the responsibility of the special purpose variants.
Thank you for your feedback btw, it's appreicated and served as a good reminder that the PKGBUILD in the AUR had not been updated to reflect the state of the PKGBUILD in the upstream GitHub repo[5]. I've strived to follow the Python package guidelines[4] as closely as I can and hope that's reflected in the PKGBUILD's now.
I'm always happy to provide feedback and help each other out. Thank you for being open and reflective and also asking questions you'd like to get an opinion on. I wish you good luck for the vote, Levente