Re: Why do packages disappear?

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 <madpilot@FreeBSD.org>