On 3/30/23 11:16, Levente Polyak wrote:
On 3/29/23 15:43, Anton Hvornum wrote:
On 3/26/23 13:43, Levente Polyak 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
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.
Thank you for taking the time to explain it very elegantly! It's really
appreciated.
I wish you good luck for the vote,
Again thank you! Hoping for the best! :D
//Anton
