Re: How to (better) deal with library major API changes

Never mind, not sure if it was the best way but I did: $ fedpkg clone openexr openexr2 And then edited .git/config and updated the references and then: $ fedpkg push And it's all there. Just had to cope over my spec file modifications. Thanks, Richard

Re: How to (better) deal with library major API changes

On Sun, Jul 4, 2021 at 2:05 PM Miro Hrončok wrote: > > Technically, you only need --exception, but I also like to use > --no-initial-commit, so the package can be imported with git history of > openexr. > Ok, I did that, now how do I import the current openexr repo? Thanks, Richard

Re: How to (better) deal with library major API changes

On Sun, Jul 04, 2021 at 09:04:55PM +0200, Miro Hrončok wrote: > On 04. 07. 21 16:49, Richard Shaw wrote: > >On Thu, Jul 1, 2021 at 12:25 PM Miro Hrončok >> wrote: > > > >On 01. 07. 21 18:20, Richard Shaw wrote: > > > On Thu, Jul 1, 2021 at 11:11 AM Miro Hrončok

Re: How to (better) deal with library major API changes

On 04. 07. 21 16:49, Richard Shaw wrote: On Thu, Jul 1, 2021 at 12:25 PM Miro Hrončok > wrote: On 01. 07. 21 18:20, Richard Shaw wrote: > On Thu, Jul 1, 2021 at 11:11 AM Miro Hrončok mailto:mhron...@redhat.com> >

Re: How to (better) deal with library major API changes

On Sun, Jul 04, 2021 at 07:11:14AM -0500, Richard Shaw wrote: > On Thu, Jul 1, 2021 at 1:52 PM Richard W.M. Jones wrote: > https://akkadia.org/drepper/dsohowto.pdf > > as well as: > > https://gcc.gnu.org/wiki/SymbolVersioning > > > Is that something that can be easily implemented

Re: How to (better) deal with library major API changes

On Thu, Jul 1, 2021 at 12:25 PM Miro Hrončok wrote: > On 01. 07. 21 18:20, Richard Shaw wrote: > > On Thu, Jul 1, 2021 at 11:11 AM Miro Hrončok > > wrote: > > > > On 01. 07. 21 17:53, Richard Shaw wrote: > > > 1. Create a compat or SOVERSION appended package

Re: How to (better) deal with library major API changes

On Thu, Jul 1, 2021 at 1:52 PM Richard W.M. Jones wrote: > > I don't think that's what Kaleb was suggesting. Coin2/3/4 packages > contain different SONAMEs: > > # dnf repoquery -l Coin4 | grep /usr/lib64 > /usr/lib64/libCoin.so.4.0.0 > /usr/lib64/libCoin.so.80 > # dnf repoquery -l Coin3 | grep

Re: How to (better) deal with library major API changes

On Thu, Jul 01, 2021 at 12:52:51PM -0500, Richard Shaw wrote: > On Thu, Jul 1, 2021 at 12:35 PM Kaleb Keithley wrote: > > > > Or, if I may be so bold— > > Convince the developers to use versioned symbols when they break the API/ > ABI. > > This is the 21st Century, and we

Re: How to (better) deal with library major API changes

On Thu, Jul 1, 2021 at 12:35 PM Kaleb Keithley wrote: > > > Or, if I may be so bold— > > Convince the developers to use versioned symbols when they break the > API/ABI. > > This is the 21st Century, and we have solutions for this. It's not rocket > surgery. > > > That's actually not a problem

Re: How to (better) deal with library major API changes

Or, if I may be so bold— Convince the developers to use versioned symbols when they break the API/ABI. This is the 21st Century, and we have solutions for this. It's not rocket surgery. On Thu, Jul 1, 2021 at 11:55 AM Richard Shaw wrote: > I'm still trying to figure out the best way to

Re: How to (better) deal with library major API changes

On 01. 07. 21 18:20, Richard Shaw wrote: On Thu, Jul 1, 2021 at 11:11 AM Miro Hrončok > wrote: On 01. 07. 21 17:53, Richard Shaw wrote: > 1. Create a compat or SOVERSION appended package (requires new review) Packages created so that multiple versions

Re: How to (better) deal with library major API changes

On Thu, Jul 1, 2021 at 11:11 AM Miro Hrončok wrote: > On 01. 07. 21 17:53, Richard Shaw wrote: > > 1. Create a compat or SOVERSION appended package (requires new review) > > Packages created so that multiple versions of the same package can coexist > in > the distribution does not require a new

Re: How to (better) deal with library major API changes

On 01. 07. 21 17:53, Richard Shaw wrote: 1. Create a compat or SOVERSION appended package (requires new review) Packages created so that multiple versions of the same package can coexist in the distribution does not require a new review:

How to (better) deal with library major API changes

I'm still trying to figure out the best way to frame the problem and I don't have a specific solution in mind, but there's got to be a better solution for dealing with projects that make major API changes. Pre-side-tag this was even more difficult: 1. Make sure the new version builds 2. Maybe do