radicale

[jason1987d]

• New package: python3-libpass-.9.3
• python3-argon2-cffi-bindings: update to 25.1.0.
• python3-argon2: update to 25.1.0.
• radicale: update to 3.6.0.

Testing the changes

• I tested the changes in this PR: YES

Local build testing

• I built this PR locally for my native architecture, x86_64-libc

[jason1987d]

My main concern is with passlib. The original passlib was super out of date and wask forked. The python module it provides had its name changed to 'libpass' with the fork. Would this update be fine or should something with "transitional dummy package" be added and/or a package name of python3-libpass?

From searching void-packages I've found the following packages other than radicale to have some sort of dependency on python3-passlib:

• ansible-core
• libxcrypt
• mitmproxy
• salt

My other question, should I take maintainer ownership of the argon and passlib packages?

[classabbyamp]

python3-passlib and python3-libpass should be different packages. only radicale uses libpass so far.

[jason1987d]

python3-passlib and python3-libpass should be different packages. only radicale uses libpass so far.

Did that, now there's a conflict for x86_64 only. Wondering why.
I heard xlocate only exists on x86_64 for the CI. I must have been wrong about the python site-packages folder, it uses 'passlib' for the 'libpass' package. Maybe my first approach was correct and should be reverted to that?

[jason1987d]

python3-passlib and python3-libpass should be different packages. only radicale uses libpass so far.

Did that, now there's a conflict for x86_64 only. Wondering why. I heard xlocate only exists on x86_64 for the CI. I must have been wrong about the python site-packages folder, it uses 'passlib' for the 'libpass' package. Maybe my first approach was correct and should be reverted to that?

I went ahead with my first approach, of updating passlib rather than renaming or creating any new packages. The PR compiles without issues here.

[classabbyamp]

they are going to have to conflict. we can't assume the packages still using the old package are compatible with the new one. at least one of those is refusing to switch to the fork due to not trusting it

[jason1987d]

they are going to have to conflict. we can't assume the packages still using the old package are compatible with the new one. at least one of those is refusing to switch to the fork due to not trusting it

Thank you for clarifying, and which approach is best to handle the conflicts that I found with CI when I did it the other way?

[classabbyamp]

the conflicts variable needs to be set in one package

[jason1987d]

the conflicts variable needs to be set in one package

Would this be perhaps in the form such as how radicale itself uses...?
replaces="radicale2<3.0.6"
i.e. replaces="passlib<=1.7.4"

[classabbyamp]

no, conflicts is not replaces

[jason1987d]

Finally figured it out. At first I thought conflicts= had to go on both packages, just one.