Currently, gnustep-base/gnustep-back-{art,cairo,xlib} block virtual/gnustep-back. However, the gnustep-2 eclass, inherited by all apps, depends on virtual/gnustep-back. Presumably, one is meant is to install one of gnustep-back-{art,cairo,xlib}, then any apps. This has two problems: * This behavior is not defined for "new style" virtuals, which is what virtual/gnustep-back is. There is no "PROVIDES" key anymore. * This is confusing and unnecessary. If simply installing an app will suffice, it should be so; moreover, multiple gnustep-back-* can be installed simultaneously without problem. Thanks!
I made one mistake: the different GNUstep back-end types would conflict with one another, since the installed versions all have the same name. Perhaps the different gnustep-back-* should block the other gnustep-back-*, rather than virtual/gnustep-back. Moreover, virtual/gnustep-back could use the cairo USE flag to prefer the Cairo back-end, some other USE flag to use the Xlib back-end, and default to the libart back-end -- this will automate the process.
True, it's better to allow users to directly install a gnustep application in one command :) gnustep-back-* ebuilds have been updated to block against each other
Bernard, Thanks for the update. I'm afraid, however, that in the future someone will complain that he won't be able to install the different back-ends side-by-side. The default name "libgnustep-backend" would cause a conflict, but this can be changed by passing the "--with-name=NAME" switch to the configure script. Perhaps the preferred backend, libart, could be have the default name "libgnustep-backend", and the cairo and xlib backends could be called "libgnustep-backend-cairo" and "libgnustep-backend-xlib" respectively. Then, advanced users can use these instead if they so choose, and blocks wouldn't be required at all.
could we solve something using eselect here?
Unfortunately, you can't just manage a single symlink with eselect, since AppKit is looking for a bundle specifically (of the correct major version). A bundle has a plist in addition to the actual binary which has various infos that would need to be kept in sync. Usually, users are asked to set the "GSBackend" default, or source the "config-gnustep-back-art.sh" script to do it for them and set fonts. This is the situation with the gnustep stuff in the official tree; in the overlay, the script only sets the font. There are a few ways to use eselect here: * One could combine the scripts in the official tree, "config-gnustep-base.sh" and "config-gnustep-back-art.sh", and manage the backend script run via eselect. IMHO, this is not user-friendly -- the user shouldn't have to source any scripts, even for fonts. * Use eselect to maintain a "ghost bundle" with symlinks to the desired bundle. This depends on the internals of the bundles, and so IMHO is bad practice. * Move the backend config scripts into "/etc/profile.d". eselect could manage a symlink "config-gnustep-back.{sh,csh}" that points to one of "config-gnustep-back-{art,cairo,xlib}.{sh.csh}", and this symlink is sourced by "gnustep-2.{sh,csh}".
