When a valid slot isn't set by postgresql.eselect, funny things can happen, some of which are the fault of the current module, but that's beside the point, primarily that the emerge of mail-mta/postfix fails because configure tries to parse 'eselect to set postgresql slot' as a list of library locations or files. The failure, however, does not plainly indicate that as being the issue. Reproducible: Always Steps to Reproduce: 1. eselect postgresql unset <all slots> 2. emerge mail-mta/postfix The test can be simple: if use postgres ; then if [ "$(eselect postgresql show)" = "(none)" ] ; then eerror "You must select which slot you want to build Postfix against before emerging" eerror "this package, or disable the 'postgres' USE flag." eerror "For valid slot selections:" eerror " eselect postgresql list" die "Default PostgreSQL slot not selected." fi fi You can get fancier, but with the module either a slot is set or it isn't, "(none)".
I think it would be better if the default slot was set via the postgresql ebuilds when it is first installed. That way new users don't have to configure much of anything and users with postgresql already installed should know how to use eselect to update to new versions if wanted. Actually, isn't something like this already done in the first few lines of pkg_postinst for the postgresql ebuilds?
Yes, but it doesn't prevent people from un-setting the slot.
(In reply to comment #2) > Yes, but it doesn't prevent people from un-setting the slot. Then it should be up to the postgresql eselect module to solve the problem or at least warn the user when they unset everything. Otherwise, every ebuild that uses pg_config similar to postfix (i.e. cyrus-sasl, clisp, pgperl, and a few others) would have to add some functionality like you mentioned in comment #1.
I really wish you folks would quit talking sense.
