Given that net-dns/idnkit-2.3 is a major ABI change, please expose ABI via subslot to allow depending packages to subscribe to that subslot to trigger rebuilds.
(In reply to Thomas Deutschmann from comment #0) > Given that net-dns/idnkit-2.3 is a major ABI change Given where?
I think what you mean is API, so adding the sub-SLOT would be pointless as bug #649326 obviously points to a compile-time problem.
*** This bug has been marked as a duplicate of bug 649326 ***
This is _not_ a duplicate. <net-dns/idnkit-2 installs /usr/lib64/libidnkitlite.so.1 and >=net-dns-idnkit-2 install /usr/lib64/libidnkitlite.so.2 That's the case when we provide a subslot to allow depending apps to trigger an automatic rebuild. That bind-tools is failing with doesn't matter. The built bind-tool would be broken and a rebuild would be required...
Please stop that. On the other bug, I referred to an upstream bug report showing they are considering IDNA 2008 (hence the duplicate) and a new version of bind/-tools relying on that should NOT depend on idnkit-1/libidn but on idnkit-2/libidn2. Setting a sub-SLOT dep is therefore either INVALID or a DUPLICATE. Take your pick. *** This bug has been marked as a duplicate of bug 649326 ***
Why can't you understand that this is not about bind-tools? Yes, bind-tools is _one_ popular package depending on net-dns/idnkit. bind-tools reveals that the code itself is incompatible and needs a change to work with >=idnkit-2. However, in first place, a preserved-rebuild event was triggered because idnkit removed "/usr/lib64/libidnkit.so.1" due to a major ABI change (it is now providing "/usr/lib64/libidnkit.so.2"). And that's what the bug is about. I am requesting that idnkit exposes its major ABI via subslot to allow depending packages to subscribe to this information so that we can use automatic rebuilds in general. Feel free to close as WONTFIX if _you_ don't want to fix that so I can escalate to the appropriate teams/projects for an additional opinion. I am not saying that I am _right_. Maybe I am wrong and a subslot shouldn't be exposed for this package. But then tell me technical reasons (I told you mine) and don't close this bug as duplicate of a totally different issue which is _wrong_. Thank you.
(In reply to Thomas Deutschmann from comment #6) > Why can't you understand that this is not about bind-tools? Whuh? > Yes, bind-tools is _one_ popular package depending on net-dns/idnkit. No package compiling against the 2.* version will succeed because the API changed - the headers. Setting up a sub-SLOT for automatic rebuilds does not solve the problem. > bind-tools reveals that the code itself is incompatible and needs a change > to work with >=idnkit-2. Exactly, so an automatic rebuild will always fail. Users should set the correct dependencies, either <2 or >=2. > I am requesting that idnkit exposes its major ABI via subslot to allow > depending packages to subscribe to this information so that we can use > automatic rebuilds in general. So you desire an automatic rebuild that will always fail because of the problems pointed out in bug #649326. > Feel free to close as WONTFIX if _you_ don't want to fix that so I can It's not so much *wanting*. Changing the sub-SLOT does not fix the problem you think it fixes. > escalate to the appropriate teams/projects for an additional opinion. I am > not saying that I am _right_. Maybe I am wrong and a subslot shouldn't be > exposed for this package. But then tell me technical reasons (I told you > mine) and don't close this bug as duplicate of a totally different issue > which is _wrong_. I already explained it a couple of times now. When you automatically rebuild against a different API you get problems like bug #649326. That's why this is a duplicate: you think you're fixing an ABI problem by adding a sub-SLOT, but you're actually having everyone run into the original API problem. *** This bug has been marked as a duplicate of bug 649326 ***
Dear maintainer, SONAME changed from /usr/lib64/libidnkitlite.so.1 in <idnkit-2 to /usr/lib64/libidnkitlite.so.2 with >=idnkit-2. Please add sub-slot to SONAME to support portage's automatic rebuild mechanism.
This is ridiculous.
For the last time, and I really hope you get it into your head this time: This is stupid: 1. Emerge $package that depends on idnkit-1. 2. Upgrade to idnkit-2, triggering automatic rebuild of $package. 4. See $package fail to compile because the API has changed. This is not stupid: 1. Emerge $package that depends on idnkit-1. 2. Upgrade $package to a version that requires and depends on idnkit-2. 3. Success!
(In reply to Jeroen Roovers from comment #9) > This is ridiculous. Also, your arrogance in reopening this bug report every time you try to make a point is well appreciated.
