Dne 01. 10. 20 v 12:28 Dan Horák napsal(a):
On Thu, 1 Oct 2020 12:06:51 +0200 Ondrej Dubaj odubaj@redhat.com wrote:
I see no other discussion here and related arguments not to make this update. I know it might break other packages, but it needs to be done to be according to the guidelines. I do not see it as a big problem to
for the record - compliance with the guidelines isn't the only criteria for doing packaging changes, there can be reasonable exceptions agreed or the guidelines can be modified.
I think this is a call to revisit this package and identify if there are reasonable exceptions.
The arguments for the way the package is currently done, which I were able to collect, were always vague. In once case the reason was bug and it was corrected.
I have yet to see any real evidence for the exception provided here or elsewhere. The status quo itself is not the reason.
Vít
Dan
rebuild the dependend packages with additional dependency on unixODBC-devel package, if it will be needed. Or if there will be some runtime problem, it can be easily fixed by editing the config file and dlopening the versioned libraries. If there will be a big need not to edit the config files, there is nothing simpler than installing unixODBC-devel package and everything works again.
Am I missing some other cases ?
Thanks for your ideas.
On Mon, Sep 21, 2020 at 8:13 AM Ondrej Dubaj odubaj@redhat.com wrote:
any other suggestions here ? I will be glad, if maintainers of dependent packages will share their opinions. If we fix this issue and it breaks dependent packages, simple workaround via symlink is available until the problems will be solved, so I see no reason for ignoring this problem.
On Fri, Sep 11, 2020 at 1:40 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 11. 09. 20 v 9:48 Florian Weimer napsal(a):
- Tom Hughes via devel:
On 11/09/2020 07:13, Ondrej Dubaj wrote:
> There seemed to be no big reason for moving the libraries to the > main package in the past, so I consider f34 as a good candidate for > such a change. It would be great, if you share your opinions and > concerns for this topic. Tom Lane has explained the reason on the ticket, it's because the library is often dlopened by a client application instead of being linked to.
"often" is relative. I see this mentioned for following packages:
java-1.5.0-ibm-jdbc
java-1.6.0-sun-jdbc
java-1.5.0-bea-jdbc
Which probably shares common history and at least one of them admitted the mistake [1] and started to use the versioned .so file.
So are there any other cases?
Yes, that is sufficient reason not to do the move. Third-party applications will break.
And they should be fixed. I understand there is never the right time to fix this, but if not now, then when?
Some people also really dislike installing *-devel packages in production, so there might not be an easy fix for them.
The library probably should not have a versioned soname in the first place, with backwards compatibility achieved by different means. But that does not matter now.
Thanks, Florian
Vít
[1] https://bugzilla.redhat.com/show_bug.cgi?id=215777#c24
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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