Why would I need to install all of postgres, if I don't intend to use it. E.g. what If I want to use a remote database. Because of that, I think it might be enough to just depend on libpq, which why there was a seperate ebuild created for it in the first place. Optional of course, it can still depend on the full postgres, as I understand that's what most users will do anyway. (A flag for libpq would be handy, where postgres would always require libpq, but libpq would not require postgres).
It doesn't make sense to depend on libpq, just remove postgresql from your use flags if you intend on using a remote DB (same for MySQL). echo "www-apps/gallery -postgres" >> /etc/portage/package.use And make sure you've compiled PHP with USE="postgres".
How do I have postgres support now? By removing the postgres flag, it'll build not against postgres, but also not against libpq and thus can't connect to a remote db. I think the solution is to use libpq instead of postgres as a useflag, or, make gallery depends on libpq when the postgres flag is set even.
Sigh, please read comment #1 more carefully. You request doesn't make any sense. echo "www-apps/gallery -postgres" >> /etc/portage/package.use removes the flag for gallery *only*. You just need PHP w/ postgresql support to use it w/ remote DB.
So what your saying is that the postgres flag is completly pointless in gallery and should be removed (as should the mysql flag) since it'll do whatever you have your php compiled against. (The flags don't change anything in the package) Then still, should it depend on dev-db/libpq instead of dev-db/postgresql? Just as php depends on libpq though you set the postgres flag? doing a USE="-postgres" is ugly, and it still doesn't help anything. Say, I want to install gallery with postgres support on my freshly base install, but I allready have a postgres server elsewhere, a user is going to type: USE="postgres" emerge gallery, which would then in turn emerge apache, libpq and php followed by gallery. Now it would also install the entire postgresql package, just because it's a unnesacery depend. If your saying, maybe the user wants postgres (and implicitly libpq), then yeah, but what if he didn't want gallery, but some other webapp that uses postgres and just uses whatever is available/detected from php? Re-instate the postgres flag in php to depend on postgresql instead of libpq (which makes sense, cause all an app needs to talk to a postgres db is libpq, wether it's local or remote). And thus, this is a valid bugreport for a incorrect package/useflag.
Technically, i don't the package requires anything special from mysql/postgresql since all it does is check wether the local php version was compiled with postgres and/or mysql support: use mysql && php_flags="${php_flags} mysql" use postgres && php_flags="${php_flags} postgres" i.e. why can't the RDEPEND not be removed entirly. mysql? ( dev-db/mysql ) postgres? ( >=dev-db/postgresql-7 ) As I see it, the ebuild checks wether php has postgres support, wether that be to connect to a localdb or remotedb doesn't matter to php, so it doesn't matter to gallery either. Then PHP simply needs to depend on libpq (as it does afaik).
