For now I'm supporting a user, who needs to use office database frontend. In Linux native solution of this is OO/LO Base. Because of slow PC he uses app-office/libreoffice-bin package. I use two different installations: app-office/libreoffice-bin and app-office/libreoffice. Default use flag set of =app-office/libreoffice-4.4.3.2 _installs_ (!) unoperable Base module (suggetsion about installing user-selected modules see in bug #549548). USE list of =app-office/libreoffice-4.4.3.2 contains three Base-related USE flags: - - java : Add support for Java - - mysql : Add mySQL Database support - - postgres : Add support for the postgresql database Which are far to cover all upstream-provided database-backends. Between non-present I remember at least sqlite (proper jdbc-connector available only in overlay). AFAIK java support means both building interface to external databases and LO built-in database engine (HSQLDB, similiar to MS Access). So, built without database connector interface LO Base is inoperable and normally should not be installed at all. Built-in database engine is far from perfection. So it may be reasonable, if possible, to built LO Base with database connector interface, but without build-in database engine. If 'mysql' and 'postgres' USEs mean just building proper connectors for Base, to my mind they should not be listed in top-level USE flags, but as values of some kind use-expand. Which source file to my mind should list not only Gentoo-supported, but all upstream expected database-backends. In binary Linux distributions database connectors for LO Base are installed from separate packages. But in Gentoo (for =app-office/libreoffice-bin-4.4.3.2) I see no such facility. Installation of system-part dependencies (for example dev-java/jdbc-postgresql) looks to be not enough. So, for now app-office/libreoffice-bin in Gentoo really supports only built-in HSQLDB database. And availability of alternatives just confuses user. Not to do it app-office/libreoffice-bin (4.4.3.2) interface should block non-operable menu items. Ideally — with listing available ones prior to installation (i.e. in some kind of use, or USE_EXPAND flags) and availability fo some alternatives (the best or most popular ones) to built-in HSQLDB engine. Also greatly pleased will be some kind of unification between app-office/libreoffice and app-office/libreoffice-bin packages (the same list of Base back-ends).
Let's get these things in order: 1) Default use flag set of =app-office/libreoffice-4.4.3.2 _installs_ (!) unoperable Base module >> There's no way _not_ to install Base, but at least it is possible to get rid of the java dependency, so the option won't go away. Right now, LibreOffice warns in pkg_pretend if USE=-java: "If you plan to use lbase application you should enable java or you will get various crashes." << The default could be changed to USE=+java, if others agree. 2) Built-in database engine is far from perfection. So it may be reasonable, if possible, to built LO Base with database connector interface, but without build-in database engine. >> The java USE flag is not related to some external connector. You can either use internal hsqldb or use a system provided one, but LibreOffice ebuilds have the following comment: # hsqldb: system one is too new That hasn't changed, as upstream rather tries to move away from hsqldb rather than update it once more, and Gentoo isn't going to add back an old package version. << If you are interested in changing something about that, you could investigate how far upstream's work on an alternative backend has come. 3) If 'mysql' and 'postgres' USEs mean just building proper connectors for Base, to my mind they should not be listed in top-level USE flags, but as values of some kind use-expand. >> The pool of USE flags of a package does not state equal importance or meaning, even if some of them happen to be similar. << How about a better local metadata.xml description for java, mysql and postgres flags, wouldn't that achieve the same?
