$summary
In portage. With subslotting. I hope I got it right -- based on SONAME version
(In reply to comment #1) > In portage. With subslotting. I hope I got it right -- based on SONAME > version Wouldn't be better to wait until upstream changes soname to move to subslotting? Otherwise, people will get useless rebuilds when this 1.5.x version is moved to stable :/
(In reply to comment #2) > (In reply to comment #1) > > In portage. With subslotting. I hope I got it right -- based on SONAME > > version > > Wouldn't be better to wait until upstream changes soname to move to > subslotting? Otherwise, people will get useless rebuilds when this 1.5.x > version is moved to stable :/ When I added the subslotting, only gdk-pixbuf had :0= and was rebuilt. How does this cause useless rebuilds for stable then?
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > In portage. With subslotting. I hope I got it right -- based on SONAME > > > version > > > > Wouldn't be better to wait until upstream changes soname to move to > > subslotting? Otherwise, people will get useless rebuilds when this 1.5.x > > version is moved to stable :/ > > When I added the subslotting, only gdk-pixbuf had :0= and was rebuilt. How > does this cause useless rebuilds for stable then? If I don't misremember, when people start to add :0= to their packages looking for future soname bumps, they will get rebuild when update from SLOT="0" to "0/15" is done... or maybe I misremember how portage handles this transition :S
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > (In reply to comment #1) > > > > In portage. With subslotting. I hope I got it right -- based on SONAME > > > > version > > > > > > Wouldn't be better to wait until upstream changes soname to move to > > > subslotting? Otherwise, people will get useless rebuilds when this 1.5.x > > > version is moved to stable :/ > > > > When I added the subslotting, only gdk-pixbuf had :0= and was rebuilt. How > > does this cause useless rebuilds for stable then? > > If I don't misremember, when people start to add :0= to their packages > looking for future soname bumps, they will get rebuild when update from > SLOT="0" to "0/15" is done... or maybe I misremember how portage handles > this transition :S If we go back to 0/0 with libpng, would that trigger rebuilds from 0/15 -> 0/0 to ~arch then? I'm honestly a bit confused with this, and even more so annoyed with people adding deps like media-libs/libpng:= without the 0, like :0= as completely disregarding the SLOTting here Maybe I've missed some mail in -dev explaining how this all is supposed to work, but it seems unobvious to half of the devs currently If you are sure it's correct to go back to plain "0" from "0/15", then fine, we can do that... sounds counter productive to me :-/ I can live with some rebuilds...
I think it is a bit explained at: http://gentoo.2317880.n4.nabble.com/Subslots-progress-in-main-tree-td256646.html See Zac's comment. About people setting wrongly depends on library SLOT, I think that we could maybe enforce (via repoman) to always ask SLOTS (even 0) to be set in RDEPENDs (if a package is compatible with multiple slots, it can set :* SLOT operator)
(In reply to comment #5) > If you are sure it's correct to go back to plain "0" from "0/15", then fine, > we can do that... sounds counter productive to me :-/ I can live with some > rebuilds... Yeah, if the soname did not change, it's a good idea to change it back to 0 before this goes to stable. Rule of thumb: only bump sub-slot when something changes to justify it.
ok, done. thanks both.
