On Sun, Dec 8, 2013 at 6:57 PM, Patrick Lauer <patr...@gentoo.org> wrote: > On 12/09/2013 12:54 AM, Tom Wijsman wrote: >> >> One thing that directly comes to mind is that dependencies that have no >> SLOT="0" ebuild present would need us to manually specify a specific >> SLOT; given that this is a not so common situation, the amount of >> commits needed here is low. > > And now you make updating a lot more fun, because slotted packages need > to be explicitly changed if there's a new slot happening. Just to hide > your own laziness.
Frankly, your tone is rude here. Don't personalize things. The goal is to eliminate non-value-added work. If a change makes work for others that should be pointed out. If a change saves somebody time, that isn't "laziness." Work isn't a virtue - accomplishing something is. Discuss the merits of the proposal, and don't debate the morals of the person making the proposal. Second, I'm not sure exactly what you're trying to say here. Slotted packages don't need to be changed under the proposed approach any more than they otherwise would. If you have SLOT=0 of libfoo and want to introduce SLOT=1 it is the same amount of work for the libfoo maintainer either way. The only difference is that if half the tree depends on libfoo and breaks with libfoo:1 then there are a bazillion failures all the sudden. If you meant that packages that depend on slotted packages need to be changed, then that isn't really correct either. If a package depends on libfoo:0 instead of libfoo:*, it will work just fine when libfoo:1 is introduced - it will just continue to pull in libfoo:0. Then over time maintainers can test and add an || dep for libfoo:1 and the package will work with either. The status quo requires the libfoo maintainers to do a ton of work to get everybody to change their deps before introducing a new slot. Either that or they do what everybody else apparently does and not use slots at all, just creating libfoo2. Well, if you can't reliably create new slots for dependencies, then what is the point of having a syntax for slot dependencies in the first place? On IRC there was some discussion and it may make sense to not make the default :0 (or :0=), but rather to just not have any default in a future EAPI - every single dependency line would therefore contain a slot. I'm not convinced wildcards should even be allowed - the whole point of introducing new slots is that the new version may not be compatible, so how can you say in advance that any slot is acceptable? If the new library is API-compatible then it should just be a new subslot in the same slot, and if it is ABI-compatible then it should be in the same subslot. The whole point of subslots is to handle packages that have API breaks, and I don't see how wildcards against future versions not even written yet can be appropriate there. The only thing that it does is saves maintainers the trouble of looking up what slots the package was actually tested against, which sounds a bit like a certain word that starts with l... :) Rich
