A few key points: 1. SDL2 is not a separate library but a continuation of SDL1, 2. the API is fairly compatible, and application compatibility can be achieved with a help of a few #ifs, 3. there are applications that support both SDL1 and SDL2, and don't provide a switch to control which one will be used. Therefore, it is improper to commit SDL2 as a set of separate packages. It should be a slot of libsdl much like GTK+3 is a slot of x11-libs/gtk+. Well, in fact GTK+3 is much less compatible with GTK+2 than SDL2 is with SDL1. Having the packages separate means that e.g. pcsxr (bug #492936) needs to either: 1. be fixed at SDL2 (which makes stable users less happy), 2. block SDL2 (which makes everyone unhappy), 3. introduce hacky USE=sdl2 that conditionally blocks SDL2, 4. introduce hacky USE=sdl2 with additional build system patches just to work-around this mistake, 5. wait for a new set of 6 virtuals to cover up this mistake and make it possible to properly lock the package on single version of SDL. Considering that libsdl2 is not used yet in Gentoo for anything but itself, I suggest committing it again as slots of media-libs/libsdl and friends quickly, and adding necessary SLOT deps to reverse dependencies.
No, we're not going to be using slots for libsdl2. Changing to slots for one package, especially one that is a tiny use case like anything from games-emulation is not a compelling reason. We did consider the situation before deciding to use a separate package name.
Then please commit the necessary virtuals to make it possible to clearly support SDL2 and SDL1.
(In reply to Michał Górny from comment #2) > Then please commit the necessary virtuals to make it possible to clearly > support SDL2 and SDL1. use || ( libsdl libsdl2 )
(In reply to Julian Ospald (hasufell) from comment #3) > (In reply to Michał Górny from comment #2) > > Then please commit the necessary virtuals to make it possible to clearly > > support SDL2 and SDL1. > > use > > || ( libsdl libsdl2 ) Then unmerging a random version of SDL will break linking.
(In reply to Michał Górny from comment #4) > (In reply to Julian Ospald (hasufell) from comment #3) > > (In reply to Michał Górny from comment #2) > > > Then please commit the necessary virtuals to make it possible to clearly > > > support SDL2 and SDL1. > > > > use > > > > || ( libsdl libsdl2 ) > > Then unmerging a random version of SDL will break linking. use revdep-rebuild to fix broken linkage
(In reply to Julian Ospald (hasufell) from comment #5) > use revdep-rebuild to fix broken linkage Seriously? This is your solution? We have proper tools. The library is slottable, and we have slot operators that can prevent the breakage. Your answer is a clear violation of QA.
(In reply to Michał Górny from comment #6) > (In reply to Julian Ospald (hasufell) from comment #5) > > use revdep-rebuild to fix broken linkage > > Seriously? This is your solution? > > We have proper tools. The library is slottable, and we have slot operators > that can prevent the breakage. Your answer is a clear violation of QA. a) revdevp-rebuild is the only proper tool that works reliably for uncovering broken linkage b) preserved-libs is a relatively proper tool b) slot operators are a mess, are used wrong and many users have them disabled and don't like them c) we ASKED on dev-ML before doing the SDL2 bump... no one did object about not slotting it and no one offered help to slot it d) one usecase is not enough to cause a migration of this kind which might break a lot of other things on the way. Now... I know you don't care a lot about painful migrations, but I do. e) packages that randomly link against one version or the other are _broken_ and need a patch
(In reply to Julian Ospald (hasufell) from comment #7) > > a) revdevp-rebuild is the only proper tool that works reliably for > uncovering broken linkage Why break linkage on purpose? > b) preserved-libs is a relatively proper tool Which makes it an unreliable optional feature, irrelevant to this discussion. > b) slot operators are a mess, are used wrong and many users have them disabled and don't like them We are suggesting to slot the dependency, not introduce sub slots (as that is the only thing users can disable). Can you clarify what you consider a relevant mess and why? Which relevant use of them is wrong? > c) we ASKED on dev-ML before doing the SDL2 bump... no one did object about > not slotting it Prediction of problems is limited, this problem was invisible back then. > and no one offered help to slot it This requires at least a half thousand commits to the Portage tree; this is too much semi-automatic (with manual checking) work to accomplish, in the current state I assume that would take a month to accomplish. A much more appropriate way is to change the PMS and PMs such that the default behavior of a missing SLOT becomes :0 instead of :*; because really, "Indicates that any slot value is acceptable." as a default mismatches the way slots are being used. > d) one usecase is not enough to cause a migration of this kind which might > break a lot of other things on the way. Now... I know you don't care a lot > about painful migrations, but I do. One of many, because there are only going to be more consumers in the future; if there's a point in time we can still fix it up, that is now. Not when we're deep into the migration we have to go through anyway; whether it is painful, that depends on how you want that migration to happen. > e) packages that randomly link against one version or the other are _broken_ > and need a patch Manpower to patch up everything is limited, that's why SLOTs were invented.
(In reply to Julian Ospald (hasufell) from comment #7) > c) we ASKED on dev-ML before doing the SDL2 bump... no one did object about > not slotting it and no one offered help to slot it Did you mention back then that SDL2 is quite API-compatible with SDL1? > d) one usecase is not enough to cause a migration of this kind which might > break a lot of other things on the way. Now... I know you don't care a lot > about painful migrations, but I do. So do you expect game packages not to support two versions of SDL even if it's as easy as a conditional in configure? > e) packages that randomly link against one version or the other are _broken_ > and need a patch Since when is supporting new and old version broken? So are we supposed to patch the packages out to support only one version of SDL? How is that an improvement?
(In reply to Mr. Bones. from comment #1) > No, we're not going to be using slots for libsdl2. Changing to slots for > one package, especially one that is a tiny use case like anything from > games-emulation is not a compelling reason. We did consider the situation > before deciding to use a separate package name. I'm sorry, but being lazy is not an excuse for filling the tree with garbage. That said, a few hundred commits is a workload that merits discussion. (In reply to Julian Ospald (hasufell) from comment #7) > a) revdevp-rebuild is the only proper tool that works reliably for > uncovering broken linkage * It acts retroactively, and fixing things may be nontrivial once broken. * It does NOT work reliably (dlopen) > b) slot operators are a mess, are used wrong and many users have them > disabled and don't like them If you disable that, well, you're on your own. After all there is a reason we've introduced it, and more and more packages are relying on it. > c) we ASKED on dev-ML before doing the SDL2 bump... no one did object about > not slotting it and no one offered help to slot it Best one of all your arguments indeed. > d) one usecase is not enough to cause a migration of this kind which might > break a lot of other things on the way. Now... I know you don't care a lot > about painful migrations, but I do. Believe me, there have been enough potentially painful migrations in the past. Aaaand... surprise, people have done it carefully and with a plan, and things worked out well. (Introduce new library version package.masked. Do a build run to check for breakage. Fix things...)
(In reply to Tom Wijsman (TomWij) from comment #8) > This requires at least a half thousand commits to the Portage tree; this is > too much semi-automatic (with manual checking) work to accomplish, in the > current state I assume that would take a month to accomplish. IIUC we'll keep the current level of quality if we do these commits fully automatic (namely, replace libsdl with libsdl:<slot>). Manual checking if the reverse dependency supports both libsdl and libsdl2 would already be an _improvement_ over what we have now. Then, some 500 automated commits are not a big issue. We've done that before for other libraries.
Please note that in order to do this properly, we need to revbump the ebuilds as well. It should be enough to revbump the newest stable and unstable version though. In any case, I'm fine with any way of solving this. Games team can decide which way is better for SDL and its consumers, though I'd expect at least some of them to support both versions of SDL. I just want a working dep for my package. If work-load for modifying rev-deps is the problem, just say so and ask for help. I'm sure there will be people who will do the dirty work for you.
(In reply to Andreas K. Hüttel from comment #10) > (In reply to Mr. Bones. from comment #1) > > No, we're not going to be using slots for libsdl2. Changing to slots for > > one package, especially one that is a tiny use case like anything from > > games-emulation is not a compelling reason. We did consider the situation > > before deciding to use a separate package name. > > I'm sorry, but being lazy is not an excuse for filling the tree with garbage. > That said, a few hundred commits is a workload that merits discussion. > > (In reply to Julian Ospald (hasufell) from comment #7) > > a) revdevp-rebuild is the only proper tool that works reliably for > > uncovering broken linkage > > * It acts retroactively, and fixing things may be nontrivial once broken. That's why we have preserved-rebuild. > * It does NOT work reliably (dlopen) dlopen is totally unrelated to uncovering broken linkage. I guess I have to make this clear... it is INCORRECT that most/many packages work with both sdl versions. You don't seem to deal with a lot of those, so I don't blame you for not knowing. 95% of the packages that support both versions have a) a build-time switch and b) different set of bugs for sdl and sdl2 (usually more with sdl2). Many projects also just convert straight to sdl2, such as openmw. Randomly mixing up these libs, because ONE application happens to support them without a build-time switch does not make any sense. That is called an "automagic" dependency and is a QA problem. So I suggest you fix that package instead of suggesting that we fix ~500 packages for a single usecase. I suggest you just force the version that works best and talk with upstream about which one that is... pretty similar to what we do with gtk+:2 vs gtk+:3.
(In reply to Ulrich Müller from comment #11) > (In reply to Tom Wijsman (TomWij) from comment #8) > > This requires at least a half thousand commits to the Portage tree; this is > > too much semi-automatic (with manual checking) work to accomplish, in the > > current state I assume that would take a month to accomplish. > > IIUC we'll keep the current level of quality if we do these commits fully > automatic (namely, replace libsdl with libsdl:<slot>). That's my first thought, but then what mgorny's rev bumps came to mind because of dynamic-deps functionality; this changes the question as to whether rev bumps can be fully automated. This is where I think things need to be done more careful, because certain packages can depend on (or block) the same or different revision in certain cases; thus, while this isn't common I think we need to evaluate this properly before proceeding down this road. At the very least, we should probably have the script run against a copy which we don't commit; comparing a tree wide `repoman full` against the unmodified Portage tree to see if we have regressions. But realistically, I think that a semi-automatic approach where manual checking occurs is more favorable. This very last thing could optionally be done in an automated way by letting the script automatically first fixing up small amounts of packages; then we evaluate the results, fix up the script and gradually increase the amount of patches (10, 20, 40, ...) done on each day. (In reply to Michał Górny from comment #12) > If work-load for modifying rev-deps is the problem, just say so and ask for > help. I'm sure there will be people who will do the dirty work for you. Given it is well planned, others and I definitely would want to join the effort. (In reply to Julian Ospald (hasufell) from comment #13) > Randomly mixing up these libs, because ONE application happens to support > them without a build-time switch does not make any sense. That is called an > "automagic" dependency and is a QA problem. So I suggest you fix that > package instead of suggesting that we fix ~500 packages for a single usecase. It would be an automagic dependency if it were not listed as part of DEPEND; however, in this case it intent is to be listed there. With both slotted and libsdl:= you can easily depend on both without any repercussions if dependencies change; however, with two packages and || ( libsdl:= libsdl2:= ) you're having a more severe problem as that doesn't really work well. So while explicit SLOTs and separate packages capture a quite similar concept, the syntax as defined by PMS restricts in what you can do with them. I however agree it boils down to whether we want to support depending on both. http://wiki.libsdl.org/MigrationGuide is a good read to decide on this...
Daniel... you as arx-libertatis developer. What is your opinion on this? Is this a usecase that you care about? Do you think it is wise to automagically pick one sdl version and run different code?
Frankly, I don't see how programs supporting both SDL1 and SDL2 are relevant to media-libs/libsdl being slotted or not: Either the ebuild always uses one version of SDL (eventually this should mean SDL2) or there must be a choice (read: USE flag) for the user to choose which SDL version to use, even if both are installed (otherwise, why support SDL1 at all?) and that can be used to set the dependencies no matter how SDL is packaged. If the upstream build system doesn't support that yet, then that's a bug - or at least a suggestion that SDL1 is only a fall-back if SDL2 is absolutely not available. As for Arx Libertatis, we currently support both SDL2 and SDL1 with a compile-time switch, and the live ebuild in the arx-libertatis overlay has a sdl2 USE flag mapping to that. However I see that as more of a transitional hack until media-libs/libsdl2 is eventually stabilized. If we could rely on SDL2 to be widely available, I would drop SDL1 support completely from AL.(*) I would also like to object to the assertion that "application compatibility can be achieved with a help of a few #ifs". Well sure it can, but the same applies to most library changes for sufficiently large values of "a few". From the 201 (SDL1) and 210 (SDL2) SDL symbols we use in AL, only 64 are used in both SDL backends. I'd expect many applications to have less changes, but the entire point of SDL2 is an API redesign. In the end, SDL2 is both a continuation of SDL1 (in the sense that the former deprecates the latter and going by how the code evolved) *as well as* a separate library (with a significant API change and completely different license). Thus the choice of a SLOTted media-libs/libsdl vs. a separate media-libs/libsdl2 boils down to semantic considerations (ie: bikeshedding), at least that's my 2 satoshi. (*) To me it's rather obvious that upstream has abandoned SDL1 development (just look at the patches applied in media-libs/libsdl) and I would rather spend my time on fixing any remaining issues with SDL2 - for AL the only one I'm aware of is [1]. [1] https://bugzilla.libsdl.org/show_bug.cgi?id=2209
That's settled imo. If there are more usecases, we might reconsider.
