On 2023-02-20 10:01, Richard W.M. Jones wrote:
Does it have to be something which looks so much like it might be a
version number? For example it could be helpful for debugging if the
generated requires was something like:
Requires: libnghttp2.so.14()(64bit) >= soname.14.24.1
or:
Requires: libnghttp2.so.14()(64bit)(soname) >= 14.24.1
I don't have a *reason* to dislike the first option, but my gut reaction
is that it's messy to encode both a feature and a version into a single
field. Let's withhold judgement on that one for a moment to consider
the other.
Unless I'm missing something, the second option wouldn't be compatible
with any existing packages unless it were an addition instead of a
change. If it were an addition, we have the option of making the system
more compatible with existing packages than the current proposal by
using a rich dependency. Assuming the generator is allowed to emit rich
deps (which I have not verified), the generator could emit:
Provides: libnghttp2.so.14()(64bit)(soname) >= 14.24.1
and:
Requires: (libnghttp2.so.14()(64bit)(soname) >= 14.24.1 if
libnghttp2.so.14()(64bit)(soname))
And in that arrangement, the deployment can be completed faster because
packages only require a versioned library "provide" if the providing
package has the versioned library feature, which also improves
compatibility with third party repos that don't adopt the feature
(assuming that users want those packages to provide something that a
Fedora package requires, which seems very uncommon).
But that compatibility upside is a reliability down side. Imagine a
system that has libfoo 1.2.3 which "Provides:
libfoo.so.1()(64bit)(soname) = 1.2.3" + "Provides:
libfoo.so.1()(64bit)", and the maintainer updates to a git version with
libfoo.so.1.3.0git. That will only "Provides: libfoo.so.1()(64bit)".
If they also rebuild an associated program, it might require new
interfaces from libfoo, but only "Requires: libfoo.so.1()(64bit)", (and
any versioned requirements stop working) so installing the application
wouldn't trigger an update of the library, which is the intent of this
feature.
That might be worth further thought... at the moment I dislike the way
it degrades.
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
