On 21/11/23 22:00, Edward Sanford Sutton, III wrote:
On 11/21/23 09:21, Guido Falsi wrote:
On 21/11/23 16:39, Richard Childers wrote:
I was using ungoogled-chromium and I had 60+ tabs that I can now not
get back because ungoogled-chromium has been withdrawn from circulation.
why are these packages appearing and disappearing? If it's a package,
it's supposed to be good enough to public use. The experimental stuff
is supposed to stay in the ports section, not be promoted to packages.
Can you explain what you mean by "disappear"?
If the problem is that from time to time the package is not present in
the set of official packages, that is most probably due to the package
failing to build in the last run, which could be due to many many
reasons (*). If you track quarterly it should happen less frequently.
If by disappear you mean that pkg unexpectedly removed it from your
system, pkg should have stated that it wanted to do that and why, and
maybe some investigation is required.
It should always be listed that it will be removed but in my experience
it does not state 'why'. Usually it is the result of dependency updates
need a new version of the package and the new version isn't in the
repository; to complete the update of what is installed and in the
repository, the package will be removed instead of left installed+broken.
Well it not always states why, you are right, but stopping pkg before it
performs the update and analyzing things usually sheds some light.
Anyway pkg has not been removing packages only because they are not
present in the repo for a long time (I do remember this used to happen
in the early days when it was still named pkgng)
I do wish it said why and I also wish there was a way to say to perform
upgrades but not upgrade things if they relate to a specified port;
locking the port that would be removed would leave it, but also would
still permit its dependencies to upgrade even if the locked port broke
last I tested it.
This is something that requires operator intervention, locking locks
only that package, that is the semantics, if you want to lock all
dependencies you should do it by hand (can also be automated with a pkg
query pipe I guess).
But I don't see an easy solution to what you report. I am not able to
suggest patches to pkg in this direction.
--
Guido Falsi <madpi...@freebsd.org>
