Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 16 Apr 2022 16:36:34 +0100
From:      tech-lists <tech-lists@zyxst.net>
To:        freebsd-questions@freebsd.org
Subject:   Re: Changes (was: nvidia-driver and no update in /usr/ports/UPDATING)
Message-ID:  <YlriggJ/0ajwu4k%2B@cloud9.zyxst.net>
In-Reply-To: <CC3F4336-9095-4B7D-8F8D-A49D4A3FA62E@gromit.dlib.vt.edu>
References:  <Yk9tEmvtQB5JEWoz@cloud9.zyxst.net> <Yk%2Bfip5KdWYjn99h@cloud9.zyxst.net> <16715f81-49c7-9710-d4f4-2a555f0eff74@gmail.com> <YlYc/91DTwp5aoMP@cloud9.zyxst.net> <CC3F4336-9095-4B7D-8F8D-A49D4A3FA62E@gromit.dlib.vt.edu>

index | next in thread | previous in thread | raw e-mail

[-- Attachment #1 --]
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.

[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmJa4ngACgkQs8o7QhFz
NAUXgw//bXR2ugtZP0Bym7Zf4e7RGC6dNsQTKTAqKDF/0E/1uvlfFoJVr7Qh0YGU
1DHtvwQ60FKjzomM88nfMsADxqymWbmrzzbFCr6F8tkW6A7W5c4lbEAyuM5usevA
c//t129y9aqv/Eo6zB8Z6wffkmIE3DW2dNg3sDNDKGinFvUwhrdQOToNkQb/Q5UD
4LVwPosFuQHt7tL7F7Ax0ePlbRDo0ch3q5JqcygJFvuIEQbC3l7FyqQqgCu+1zXO
HzPqL6pB+sUZGGWdor/F9sN8KPOoLpr34XbMR/YF9QkrWzjXzakN4xe7Pa9UYK7L
CI1gH96PcMiJU15OApNlEFrCE09EeXe45odiJSlRh8pCgTBqqCiMhHByQh/CztDh
W2Qh9sRMF3KxdFUEsNLhi/xx4mh4taCxGcDMGMuWe1PAMajhgo3NdFaJ9MdabRA2
TuSu1TdPGKQjC4c39TAa4bPFZr0DdcIsa0y03ZSTZrmePutOcgGFG6SOkH6F/Zp+
MgcV3AgSPqsn78vHneKaA4foG/83dsOOWuaZQ7JJ44HS/bH/zU9th2q737M1LT0I
XNzKXm5+9zwW0t2eV1WxCzuymXtdnd4peT3iT6kUL27pheURp2URhx/nMSOzz0IQ
ivHsWHca24l0fps1my3kSF3Wc0kX12Y8WCtgEp8xAF/yRpUq+XQ=
=umth
-----END PGP SIGNATURE-----
home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YlriggJ/0ajwu4k%2B>