Re: Changes (was: nvidia-driver and no update in /usr/ports/UPDATING)

Hello,

On Tue, Apr 12, 2022 at 09:25:04PM -0400, Paul Mather wrote:

> Have you considered tracking the quarterly ports branch instead, 
> if you want less volatility?  (IMHO, the quarterly branch brings 
> its own set of issues, so this may not be a good solution for you.)

I've considered it but immediately discounted it, because 
almost all the systems I manage are connected to the internet
in some way. So, as vulns and patches arise, ports need
to be rebuilt and installed, and we have a large poudriere
system for that purpose specifically.

But the issue anyway is not in volatility of ports.
It is that breaking changes are not documented in UPDATING.
This is the crux of the matter.

> Also, do you have a dev/test environment where you can 
> smoke-test changes before deploying them in production?

Yes I have. It was there where the issue with the font was sensed.
When updates on production happened, I was able to see the
full effects of the damage caused, because I was looking for 
exactly that, and was able to catch it. 

The reason it had to briefly go to production
is that although devel has all the software, it doesn't
(and cannot) have all the hardware. The only reason I was
able to "sense" beforehand was because I was *watching*
poudriere compile for this particular port. So it was literally
luck that gave me the information to anticipate breakage. 

I can't depend on luck to run anything but a toy system. 
If I wasn't looking at the screen at the time, it would have 
been missed.

With regard to x11/nvidia-driver, it concerns a system 
with no devel equivalent because it is in itself a graphical
workstation used in development.

> Finally, have you considered subscribing to the ports mailing 
> list, where reports of breakage and heads-up on potentially 
> dangerous change often surface (along with solutions/workarounds)?

I am subscribed and I do read that list. But it's a very busy list 
and I'm just a human being. There are not enough hours in the day to
read and filter that one list. In a typical FAMP setup there might be
over 300 packages. On this desktop, there are over 1500. 
In any case, these changes might not make that list.

We appear to live in a time where screen(8) changes make it into
updating, but x11/nvidia-driver (the last straw, which triggered
my initial post), which needs to be compiled with kernel sources,
doesn't.

> FWIW, I've also fallen foul of tardy or absent ports UPDATING 
> entries that have left me temporarily broken, so I feel your pain.  
> I've learned to counter it with more rigorous QA on my part. :-)

It really should be mechanically impossible to make breaking
changes without a line or two in UPDATING beforehand. Literally 
the date, what port has changed, look at ports list for further 
details, so that the user can take action to prevent breakage. 

It would be simple then for the user to automate a process which 
compares UPDATING to a live list of installed ports. But this 
kind of thing can't be addressed in a bugzilla report. 
I don't know how it could be addressed.

thanks for writing,
-- 
J.