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>
next in thread | previous in thread | raw e-mail | index | archive | help
--dmB/unLWEPHps3yW Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, On Tue, Apr 12, 2022 at 09:25:04PM -0400, Paul Mather wrote: > Have you considered tracking the quarterly ports branch instead,=20 > if you want less volatility? (IMHO, the quarterly branch brings=20 > its own set of issues, so this may not be a good solution for you.) I've considered it but immediately discounted it, because=20 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=20 > 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=20 exactly that, and was able to catch it.=20 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.=20 I can't depend on luck to run anything but a toy system.=20 If I wasn't looking at the screen at the time, it would have=20 been missed. With regard to x11/nvidia-driver, it concerns a system=20 with no devel equivalent because it is in itself a graphical workstation used in development. > Finally, have you considered subscribing to the ports mailing=20 > list, where reports of breakage and heads-up on potentially=20 > dangerous change often surface (along with solutions/workarounds)? I am subscribed and I do read that list. But it's a very busy list=20 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.=20 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=20 > entries that have left me temporarily broken, so I feel your pain. =20 > 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=20 the date, what port has changed, look at ports list for further=20 details, so that the user can take action to prevent breakage.=20 It would be simple then for the user to automate a process which=20 compares UPDATING to a live list of installed ports. But this=20 kind of thing can't be addressed in a bugzilla report.=20 I don't know how it could be addressed. thanks for writing, --=20 J. --dmB/unLWEPHps3yW Content-Type: application/pgp-signature; name="signature.asc" -----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----- --dmB/unLWEPHps3yW--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YlriggJ/0ajwu4k%2B>