> > 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"