I think sqlgui ebuild should take care of use variables and not blindly depend on mysql. The same program can be compiled for postgres only use, (maybe we can make additional split to sqlgui plugins that way sqlguipart and sqlgui wouldnt depend on any DB ? but on sqlgui-plugin ?) Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 16769 [details] sqlgui,sqguipart,sqlguipgsql ebuilds with digests (0.5.1,0.5.1,0.1.1) This is a collection of ebuilds for sqlgui package it hase ebuilds for sqlgui (client 0.5.1), sqlguipart (backend 0.5.1), sqlguipgsql (pgsql backend 0.5.1) there is no mysql backend ebuild becuase i dont have mysql installed to test it however i think just small changes to sqlguipgsql will convert it to mysql :) this still does not have full dependacy checking nor use variable check :( sqlgui is dependant on sqlguipart however database specific backend isnt dependent on anything (it can be actualy compiled and installed separately from rest, it may ahve some use like that for someone but i guess its rare) this should eb a good begin of a better sqlgui build system current (v0.4.0) isnt sufficient specialy becuase its fully mysql oriented. any comments here or on direct to me
Created attachment 16771 [details] ebuild for mysql backend of sqlguipart (sqlgui) *NOT TESTED* Here is a mysql backend ebuild (no dependecy setup at all except kde) this is not tested compiliation breaks on my machine becuase of missing mysql headers, so if someone want to test it go ahead and tell me did it work. to do anything usefull with this install sqlgui and sqlguipart (previous attachment has builds for it) I guess sqlgui,sqlguipart 0.5.1 can make use of this (older version could too never tested) again this is not tested
If you are still using this and these apps are still maintained upstream, then attach plaintext ebuilds for current versions of these tools and reopen then.
See above.
