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
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
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
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
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
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 -
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
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,
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
* 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
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
>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
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
13 matches
Mail list logo
