Arch Linux User Repository

PSA: libyang4 isn't supported yet as of frr-10.5.0, so I've forked libyang into this package for your convenience.

@vitaliikuzhdin

The short answer is that it is not allowed on Arch. The long answer is that packages which list provides must be fully functional drop-in replacements for what they provide.

"Not allowed" source? Also this package provides libyang=3, which is accurate and not the same as libyang=4 implicitly provided by libyang.

However, if someone builds a package against libyang.so.4, they could later install libyang.so.3, since this package claims to be identical, and then get an error about missing libraries.

That is their problem not mine. Also this is exactly what rebuild-detector is for.

That creates too many package variations that neither upstream nor downstream maintainers will support.

Are you one of these upstream or downstream maintainers? If so please state your case. Otherwise please don't speak on others' behalf.

Additionally, this leads to situations where dependencies have to be dynamic, as reported for your frr package with xxhash, which is also not allowed.

This makes zero sense. And source for "not allowed"?

It really is not that hard.

You do it then. Talk is cheap. Send patches.

If you are not willing to maintain the package, you can always orphan or delete it.

I am maintaining the package, just not how you like it. And that's entirely within my rights. If you disagree, you can file a request.

Why did you upload this package?

Because otherwise frr cannot build.

If this package is useful, as mentioned in the pinned comment, it should follow the rules.

What rules? You talk a lot about "rules" but cite nothing.

@cyqsimon,

Please explain why.

The short answer is that it is not allowed on Arch. The long answer is that packages which list provides must be fully functional drop-in replacements for what they provide. However, if someone builds a package against libyang.so.4, they could later install libyang.so.3, since this package claims to be identical, and then get an error about missing libraries. Building a package against libyang.so.3 that can also be built against libyang.so.4 is also a bad idea. That creates too many package variations that neither upstream nor downstream maintainers will support. Additionally, this leads to situations where dependencies have to be dynamic, as reported for your frr package with xxhash, which is also not allowed.

That's a non-trivial amount of work given that nearly all files conflict, for which I do not have the spare time. I will accept a patch if you can provide one.

It really is not that hard. Just take a look at, for example, dcmtk18. If you are not willing to maintain the package, you can always orphan or delete it.

Also, why not just use libyang?

That is a question for you. Why did you upload this package? If this package is useful, as mentioned in the pinned comment, it should follow the rules. If it is not useful, there is no reason to keep it at all.

Please remove all provides and conflicts as they are incorrect

Please explain why.

and make this package coexist with the up-to-date libyang.

That's a non-trivial amount of work given that nearly all files conflict, for which I do not have the spare time. I will accept a patch if you can provide one.

Also, why not just use libyang?

Please remove all provides and conflicts as they are incorrect and make this package coexist with the up-to-date libyang.

PSA: libyang4 isn't supported yet as of frr-10.5.0, so I've forked libyang into this package for your convenience.