> On Jun 7, 2025, at 17:47, Matthew D. Fuller <[email protected]> wrote:
>
> On Mon, Jun 02, 2025 at 05:18:06PM -0700 I heard the voice of
> Dan Mahoney (Ports), and lo! it spake thus:
>>
>> As mentioned in my prior email, I’ve submitted a patch which allows
>> to flavor p5-DBD-Pg [...]
>
> My understanding of how flavors work is that they can't actually solve
> this problem, because the flavor is part of the package name, and
> package names are dependancies. Which means that flavoring p5-DBD-Pg
> doesn't actually solve the problem; you need to flavorizate all the
> things that _use_ p5-DBD-Pg so they depend on the right flavor of
> p5-DBD-Pg. And all the things that use those things, and all the
> things that use those things...
>
> So, a flavored p5-DBD-Pg would let you install that module to whatever
> version of Pg you wanted. But it doesn't do you any good with other
> packages that _depend_ on that module. So flavors quickly become
> unhelpful on non-leaf ports, except as object lessons in combinatorial
> explosion.
Mea Culpa, I think I was mentally giving Flavors more heavy-lifting-ability (or
magic) than they presently have.
In my particular case, I don’t *have* anything that (properly) depends on
p5-DBD-Pg. It’s a “functional” dependency (as in, yes, I need RT to talk to a
database of some sort), but there’s nothing in the RT50 Makefiles that calls
for them, there’s no OPTIONS_DEFINE to talk to mysql or postgres or oracle.
It’s left up to the user, so my solution is a unique case, for use only when
p5-DBD-Pg is a “leaf” package (and not a hard dependency for anything else on
the system, which happens to be the case for us only by coincicence).
That said, yes, it seems that if I pull in something that has p5-DBD-Pg as a
proper dependency (like pgtop), the solver does try to go for the default
version (and force a postgres-client upgrade on me), so this isn’t the right
answer, which is a shame. I legitimately thought the solver would respect the
fact that a flavored dependency satisfied a dependence on the main port, or I
wouldn’t have even pushed the patch.
I was sure I’ve seen flavors satisfy things *like* this, especially in cases
where either the x11 or -nox11 version of a dependency would work, but I may be
misremembering (The porter’s handbook is a little fuzzy about documenting all
the possible uses of USES* vs flavors vs options).
Someone earlier suggested that rather than making tools dependent on
postgresqlNN-client, that they could be made dependent on libpq, which is
stable and has been for years, but that would require reworking every port in
the tree, and would also require making it so the postgresqlNN-ports did *not*
provide libpq and friends, which is also a non-starter unless it all happened
all at once.
It’s a Hard Problem.
As for us:
Putting my database server on a second host feels like an ugly hack and
requires me to add additional network comms between them, with encryption
overhead for a connection that would otherwise be on a domain socket (and also
breaks my ability to snapshot pre-upgrade.)
A jail solves this a tiny bit, but it still adds complexity because it’s then
two different sets of packages to manage considering we don’t do jails anywhere
else, don’t have the puppet infra to manage things inside jails, check services
inside jails, do monitoring checks of services inside jails, means that db
backups would have to be modified to function inside the jail, etc. Our only
real use of jails is where managed by poudriere. We’re largely a “vm” shop.
Running a whole poudriere/cron/update to keep this one package in lockstep sync
with the main package repos (so that our perl version jumps when quarterly
does) also feels like overkill, but if dependencies are handled via binary, it
might work.
The simplest solution really is: pkg lock this one package, and when it breaks
(because it’s in a dir where perl no longer looks for modules), git pull the
port tree and rebuild it on-box (or via our poudriere, where we’d manually
install the .pkg file).
I’d still love to see pkg throw a warning about “hey, I would upgrade this if
it weren’t locked, there’s a new version of it!”
I’d also still love to see pkg have a way to present a current copy of UPDATING
to me without having to go chase it down in a browser, and perhaps filter out
only the bits that are relevant to me, and only show the bits from the last
quarterly (but this might require UPDATING to be more structured/parseable).
If those last two things are things the day job could offer to sponsor, please
let me know or approach me at BSDCan. We do like supporting the project,
especially if it helps our pain-points, which are still less than they would be
with anything involving systemd :)
-Dan
