https://bugzilla.redhat.com/show_bug.cgi?id=2080743
Petr Menšík <pemensik(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags|needinfo?(pemensik(a)redhat.c |
|om) |
--- Comment #9 from Petr Menšík <pemensik(a)redhat.com> ---
I wanted to package it first, then later maybe to create my own project
depending on it. I intended to use some DNSSEC functionality in it. I know no
other project using that library already, I would package it as well. But if
the development is on hold, I guess raising issue to domain crate upstream
might make sense with a question how to solve that. Not sure they are aware the
complication using only ring without alternatives makes.
I think
https://github.com/NLnetLabs/domain-tools is not yet worthy separate
package just for the sake of it.
It seems a bit weird I have to either disable partial functionality everywhere
or disable whole architecture altogether, but cannot use something in between.
Cannot just some form of conflict prevent installing the development headers on
problematic architectures, but include them in source archive? So it would
allow marking just affected subpackages to be non-installable on missing
architectures?
But because I have not yet code using DNSSEC validation, I think cut off
package is possible until we have a better option. I would prefer having fully
working Intel and ARM builds and no package for ppc64le and s390x. I do not
have any of those rare architectures and I guess I am not the only one.
Anyway, would update to 0.7.2 and recheck, what could be done with it.
--
You are receiving this mail because:
You are always notified about changes to this product and component
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2080743