On Fri, Jan 9, 2026, at 2:03 AM, Baptiste Daroussin wrote: > On Thu 08 Jan 19:45, Dan Langille wrote: >> re: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292266 >> >> I'm looking at adding mysql and mariadb flavors to net-mgmt/librenms >> >> Getting @mysql working is fine: >> >> +.if ${FLAVOR:U} == mysql >> +USES+= mysql:client >> +.endif >> >> The problem seems to be specifying mariadb. I've been basing it on: >> >> +.if ${FLAVOR:U} == mariadb >> +USES+= mysql:client MYSQL_FLAVOUR= mariadb >> +.endif >> >> That's no good. That just gives: Unknown USES=MYSQL_FLAVOUR=mariadb >> >> The USES docs[1] mentions "The m and p suffixes are for the MariaDB and >> Percona variants of MySQL" - yet that requires me to know and select a >> version, >> something I'd prefer to leave up to the ports tree / user. That's also what >> MySQL >> does. >> >> Reading Mk/Uses/mysql.mk[2], it sets `MYSQL_FLAVOUR= mariadb` only if >> that version >> mentioned above is specified. >> >> I've grep'd for examples, found none. >> >> When I get to blocks like this, I figure I'm doing it wrong. >> >> Am I? >> >> >> 1 - https://docs.freebsd.org/en/books/porters-handbook/uses/#uses-mysql >> mentions >> >> 2 - https://cgit.freebsd.org/ports/tree/Mk/Uses/mysql.mk#n108 >> -- > > Please do not had flavors for something like this is a step in the wrong > direction > I already pointed for years what should be done instead to people can decide > at runtime which mysql implementation they want by default, we should entirely > rework the mysql port (and the postgresql port while we are here) to avoid > adding flavors for this. This kind of use case is clearly an abuse of the > flavor > framework. > > What should be done instead: > All mysql clients and servers installs themselves in a non conflicting way > They do not expose their public libraries. the cli in the path is renamed to > make sure they do not conflict. > > We have a single default mysql client which is always the latest and greatest > available this is where we can play with the default version framework, to > maybe > allow to chose a another implementation by default if really this is needed. > (they are for now at least all compatible). > > All ports depends only on this default client and not on a specific > implementation everyone can install the version they want, have qualified are > done with it.
When i'm finding my goal particularly difficult to achieve, I'm usually doing it wrong. I like the advice - in short, make the port database ignorant / agnostic ; let the user decide at run time. That would also let the user *change* databases later without having to rebuild / reinstall the port. -- Dan Langille [email protected]
