> > IMHO this would abuse the package name for information that absolutely > > doesn't belong there. It belongs in PV or SLOT. > > > > To me it seems that you try to work around a problem (greedy upgrade > > behaviour) that should really be solved in the package manager. > > In my opinion, it's the other way around. We have slots, that are a fit > solution for packages that are roughly compatible between every major > release, and we keep abusing them for every single thing we can bend > enough to make it fit. > > It's as meaningless as having sqlite3 packaged as sqlite:3, or gtk that > is now randomly split between gtk+:2, gtk+:3 and gtk:4. SLOTs in my view, and in documentation descriptions, `ebuild(5)`, are listed as "a package that may need to have multiple versions co-exist". seemingly giving more semantics to package versions. such semantics don't exist in other distros, so they represent them with different packages. doing the same here feels like a hack, going around a limitation of the SLOT system, and not the ideal solution at all. i'd think instead looking for improving the SLOT system so that dependencies can be even more structurally declared would be the ideal solution, making different packages just breaks those semantics to work around it's limitations. > In fact, when you are never supposed to depend on the package without > specifying a slot, why would you think slots are the right solution? so yes i do think they're the right solution still, as they communicate "this is the same package, the same project, just a different version and this package needs *this* version". doing that is no different than DEPEND="=foo/nya-4.2"