Re: net-mgmt/librenms: creating mariadb and mysql flavors

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]