In the headers of this file, no SLOT value is declared. cf with the developer's handbook which says that SLOT is compulsory. SLOT is in fact set by the inherited webapp.eclass file, however the inherited value is ${PVR}, not 0 like the other ebuilds for gallery. This means that gentoo thinks that in can install the two versions side by side, rather than upgrading.
This is intention. As you said SLOT gets set by the eclass. The new ebuilds are slotted to ${PVR} as they can be installed parallel, as they're installed by webapp-config after the package has been merged.
Does that mean gallery-1.4.4.ebuild, which *does* have a SLOT variable is incorrect? Does it also mean that if one wishes to upgrade, one needs to emerge unmerge gallery, then emerge gallery?
No, it's just that the old ebuilds are not webapp-compatible and so they're slotted to 0. The new way is to slot the ebuilds to ${PVR} to be webapp-config-compatible. The old ebuilds with SLOT="0" will be removed sometime in the future. Normally the webapp.eclass-compatible ebuilds block the non-compatible ebuilds. This is how it was done with phpmyadmin. This way the user knows that he has to unmerge the old version and re-emerge the new version. Seems like it was not done with gallery. Generally it should be possible to have an ebuild with SLOT="0" and some webapp-compatible ebuild installed. But the general way of upgrading is to unmerge the old SLOT="0" version and then merge a webapp-compatible version and use webapp-config to install the package in a virtual host. Reassigning to web-apps@g.o as it's their territory.
No longer an issue.
