Re: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
On Thu, Oct 1, 2020 at 6:21 AM Ondrej Dubaj wrote: > My apologies, of course we are aiming to package the unversioned symbolic > links to the "real" libraries to *-devel package. I thought it was clear > from the beginning. > Ahh... I didn't get that from the initial message, I haven't looked into the package and assumed the soversion didn't exist, because why else would the .so files be in the main package to begin with. Thanks, Richard ___ 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
Re: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
Rebuild of dependent packages with the new unixODBC seems to be quite optimistic. The are only few failures and none of them seems to be caused by some missing libraries. We can now discuss only about the runtime problems, as it seems, almost no buildtime problems occurred https://copr.fedorainfracloud.org/coprs/odubaj/unixODBC/builds/ On Thu, Oct 1, 2020 at 1:20 PM Ondrej Dubaj wrote: > My apologies, of course we are aiming to package the unversioned symbolic > links to the "real" libraries to *-devel package. I thought it was clear > from the beginning. > > Why should we hack the soversion ? There are no changes to the soname or > ABI compatibility coming, we want to just package the unversioned symbolic > links to the "real" libraries to *-devel package. > > On Thu, Oct 1, 2020 at 1:14 PM Richard Shaw wrote: > >> Adding my $0.02 here... >> >> Since they are real libraries, they don't belong in a -devel package, the >> intent is to package the unversioned symbolic links to the "real" >> libraries. A end user package should never require a -devel package to run. >> >> One option would be to hack in a soversion to the build process. I did >> this for many years with openCOLLADA, and used either >> abi-compliance-checker or abipkgdiff to determine when a soversion bump was >> required. >> >> Thanks, >> Richard >> ___ >> 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
Re: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
My apologies, of course we are aiming to package the unversioned symbolic links to the "real" libraries to *-devel package. I thought it was clear from the beginning. Why should we hack the soversion ? There are no changes to the soname or ABI compatibility coming, we want to just package the unversioned symbolic links to the "real" libraries to *-devel package. On Thu, Oct 1, 2020 at 1:14 PM Richard Shaw wrote: > Adding my $0.02 here... > > Since they are real libraries, they don't belong in a -devel package, the > intent is to package the unversioned symbolic links to the "real" > libraries. A end user package should never require a -devel package to run. > > One option would be to hack in a soversion to the build process. I did > this for many years with openCOLLADA, and used either > abi-compliance-checker or abipkgdiff to determine when a soversion bump was > required. > > Thanks, > Richard > ___ > 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
Re: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
Adding my $0.02 here... Since they are real libraries, they don't belong in a -devel package, the intent is to package the unversioned symbolic links to the "real" libraries. A end user package should never require a -devel package to run. One option would be to hack in a soversion to the build process. I did this for many years with openCOLLADA, and used either abi-compliance-checker or abipkgdiff to determine when a soversion bump was required. Thanks, Richard ___ 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
Re: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
Dne 01. 10. 20 v 12:28 Dan Horák napsal(a): > On Thu, 1 Oct 2020 12:06:51 +0200 > Ondrej Dubaj 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 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 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 ___ 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
Re: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
On Thu, 1 Oct 2020 12:06:51 +0200 Ondrej Dubaj 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 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 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
Re: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
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 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 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 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
Re: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
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 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
Re: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
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
Re: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
* 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. Yes, that is sufficient reason not to do the move. Third-party applications will break. 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 -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ 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
Re: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
On Fri, Sep 11, 2020 at 9:15 AM Lukas Javorsky wrote:
> From my point of view, it's a good idea to move them into the *-devel
> package.
>
> It's more effective and ordered for future development.
> Because if someone only needs a few libraries, they don't have to require
> the whole main package and can just require a devel package, which is the
> way we want it as far as I know.
>
That is not the case we are aiming for, as unixODBC-devel requires
unixODBC, so the devel package will pull the main package as a dependency
during installation. The aim is that the main package should not contain
the unversioned shared libraries, as they are supposed to be used during
development and not dynamic linking. But there might be a problem if client
applications dynamically load the unversioned libraries, are they actually
able to dlopen the versioned ones ? Even if using some kind of config file
to specify the version of the shared library?
Thanks,
Ondrej
>
> Lukas
>
> On Fri, Sep 11, 2020 at 8:14 AM Ondrej Dubaj wrote:
>
>> Hello everyone,
>>
>> I would like to start a discussion about moving unversioned *.so files
>> back to unixODBC-devel package, as they are currently in the main package.
>> The reason for this discussion is primary have things in order according to
>> future rhel-9.
>>
>> There will potentially be a change of moving 5 files {libodbc.so
>> libodbcinst.so libodbcpsqlS.so libodbcmyS.so libtdsS.so} to devel
>> package, so from the maintainers/users perspective, dependent packages will
>> have to require also the devel package and should be rebuild as well. No
>> other changes will be made.
>>
>> 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.
>>
>> Sharing also the official documentation [1], tracker in bugzilla [2] and
>> upcoming changes in unixODBC package [3]
>>
>> Thanks!
>>
>> Ondrej
>>
>> [1]
>> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages
>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1877720
>> [3]
>> https://src.fedoraproject.org/fork/odubaj/rpms/unixODBC/c/7ecddca7cfcc4e014bf65085dd9547f1c5981138
>> ___
>> 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
>>
>
>
> --
> S pozdravom/ Best regards
>
> Lukas Javorsky
>
> Intern, Core service - Databases
>
> Red Hat
>
> Purkyňova 115 (TPB-C)
>
> 612 00 Brno - Královo Pole
>
> ljavo...@redhat.com
>
> ___
> 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
Re: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
>From my point of view, it's a good idea to move them into the *-devel
package.
It's more effective and ordered for future development.
Because if someone only needs a few libraries, they don't have to require
the whole main package and can just require a devel package, which is the
way we want it as far as I know.
Lukas
On Fri, Sep 11, 2020 at 8:14 AM Ondrej Dubaj wrote:
> Hello everyone,
>
> I would like to start a discussion about moving unversioned *.so files
> back to unixODBC-devel package, as they are currently in the main package.
> The reason for this discussion is primary have things in order according to
> future rhel-9.
>
> There will potentially be a change of moving 5 files {libodbc.so
> libodbcinst.so libodbcpsqlS.so libodbcmyS.so libtdsS.so} to devel
> package, so from the maintainers/users perspective, dependent packages will
> have to require also the devel package and should be rebuild as well. No
> other changes will be made.
>
> 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.
>
> Sharing also the official documentation [1], tracker in bugzilla [2] and
> upcoming changes in unixODBC package [3]
>
> Thanks!
>
> Ondrej
>
> [1]
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1877720
> [3]
> https://src.fedoraproject.org/fork/odubaj/rpms/unixODBC/c/7ecddca7cfcc4e014bf65085dd9547f1c5981138
> ___
> 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
>
--
S pozdravom/ Best regards
Lukas Javorsky
Intern, Core service - Databases
Red Hat
Purkyňova 115 (TPB-C)
612 00 Brno - Královo Pole
ljavo...@redhat.com
___
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
Re: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package
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. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ 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
