On Thu, 1 Oct 2020 12:06:51 +0200
Ondrej Dubaj <odu...@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.
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 <odu...@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 <vondr...@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-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
> >>
> >
_______________________________________________
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
