On 16/08/2024 16:09, Dimitry Andric wrote:
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.
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
