On Thu, 1 Oct 2020 12:06:51 +0200 Ondrej Dubaj <odubaj@xxxxxxxxxx> 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. 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx > >> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > >> 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@xxxxxxxxxxxxxxxxxxxxxxx > >> > > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
