Re: quarterly 2024Q3 amd64 / 13.3 missing all vital packages for desktop

On 16/08/2024 16:09, Dimitry Andric wrote:
> On 16 Aug 2024, at 15:49, Chris <portmaster@bsdforge.com> wrote:
>>
>> On 2024-08-16 00:37, Miroslav Lachman wrote:
>>> On 16/08/2024 01:34, henrichhartzer@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.

The problem is that often there are many packages in "will be REMOVED" 
approval list, because for example the Python version has changed, 
flavor renamed etc., so it is often necessary to confirm such a list and 
only after downloading the packages and recalculating the dependencies 
the list of packages to be removed is changed. Sometimes not even that, 
and you simply need to go through a painful pkg upgrade with removed 
packages and then re-install the necessary packages again (because 
somewhere in the background the dependencies have changed and there are 
conflicts)

pkg upgrade is sometimes very unpredictable in what steps will 
eventually be performed.

For a couple of month I can see dconf-editor, ruby and tcl86 installed 
and deinstalled again and again. I don't use any of them, but they are 
installed as part of the pkg upgrade and the removed by pkg autoremove 
just to be installed with the next pkg upgrade.
But this is a different story than packages missing in repository.

Kind regards
Miroslav Lachman