On 16 Aug 2024, at 15:49, Chris <portmas...@bsdforge.com> wrote: > > On 2024-08-16 00:37, Miroslav Lachman wrote: >> On 16/08/2024 01:34, henrichhart...@tuta.io wrote: >>> Hi Miroslav, >>> Please see my email titled: "Quarterly backport for multimedia/x265 patch" >>> sent to this list a few hours before yours. Shortly after sending it, the >>> patch was committed to 2024Q3. Builders will have to catch up, but >>> hopefully things can be resolved. >>> I do feel like this could have been caught and fixed faster with some >>> better alerting. I've heard of pkg-fallout and know little of it, but maybe >>> it should have noticed this? Or did it? I have no idea. >>> I know it's a terrible experience when pkg is wanting to remove your >>> desktop packages in bulk. >> Thank you for pointing to this thread. >> This is really bad experience with quarterly branch. I think the branch >> should be >> published only after the successful build of main packages. Blindly created >> quarterly branch which is not working for about 6 weeks is terrible >> experience. > While I completely agree. I'm wondering if this isn't more a pkg(8) deficit. > eg; if pkg first > determined that all/most of the packages intended to be upgraded did not > exist, issue a warn, with the > option to bail/quit. Leaving the system untouched.
Last time I checked "pkg upgrade" asks "Proceed with this action? [y/N]", and the default is "N". So what you are suggesting, is already the case? This is a problem with patches (or really any distfiles) that are retrieved from websites which are not under FreeBSD's control. If those websites decide to change the contents of those files, there is not much we can do about it, and ports which used to work then simply break. If other ports depend on those, those break too, there is not much you can do, except postponing upgrades. -Dimitry
