Re: FreBSD pkgbase MUST be ebandoned

Am 15.02.26 um 23:34 schrieb Vadim Goncharov:
> On Tue, 10 Feb 2026 14:26:19 -0600 (CST)
> Mark Linimon <[email protected]> wrote:
> 
>> tl;dr: I am not going to address all of your issues.  However:
>>
>>> On 02/09/2026 4:17 PM CST Vadim Goncharov <[email protected]> wrote:
>>>
>>> They do delete ports without maintainers
>>
>> That is exactly correct and is by design -- iff the port fails to
>> build, or is known to have security problems, or is abandoned
>> upstream.
> 
> No, this is not correct. Previous decades the policy for deleting ports was
> another, keeping much more software (until ...) and this was right thing.

You are taking the discussion off rails here because I think pkgbase 
isn't the same as pkg-for-ports.

Your "right thing" about keeping ports beyond a point where upstream 
maintainers or FreeBSD portmaintainers care, also ends up preventing the 
world from moving.
   It just won't work if, for whatever port has fallen into disrepair, 
someone stands out in front of some house shouting "but you can't leave 
*my* favourite port behind".  Ports are interdependent to some degree 
(and more so with increasing numbers - there is roughly an order of 
magnitude more ports today than it was when I tried FreeBSD for the 
first time), and if you look at how many "old version" ports (ports with 
version numbers in their name) in parallel are around, just to keep 
things alive, you might as well notice that people already spent some 
effort to not just kill everything just because spidermonkey, python, or 
whatever else moved forward.

There is a lot of abandonware around and people use it as excuse to 
prevent the tree as a whole from moving default versions forward to 
remain up to date with upstreams for big packages.  Our libc kept the 
default GCC version back for a long time.  Lots of old software packages 
prevent updates of py-sphinx, python default version, having just one 
spidermonkey version, or whatnot.  But getting back on derailing the 
discussion: what does all that have to do with pkgbase?  I fail to see 
that connection, and you've fired more claims in this thread than 
substance and desires already.

>> If that's not acceptable to you, then you'd better start maintaining
>> such ports in such a way as to not have those problems.  If that
>> also means you need to fork and become the new upstream, fine.
> 
> Acceptable to me is to return policy as it was in old good times. Ports also
> get deleted for similar reasons in that times, too, but not for ridiculous
> "modern" reasons.

For people who need old ports kept alive that haven't moved with the 
times, the best bet probably is to keep a virtual machine around with 
the old requisites, and that goes a long way to keeping the rest of the 
system safe from harm through obsolete software.

What's "ridiculous" to one might be "necessary" to others.  There is no 
right and no wrong for the entire thing, there will always have to be 
compromises, and FreeBSD has invested quite a bit more to keep the 
rolling ports release complete than have others.

> Nope, I'm participating in IETF activitites and I *know* what "rough consensus"
> is and how many time it takes to achieve. And what you are desribing is NOT a
> rough consensus, it is just small group of usurpers trying to impose their
> harmful decision on others. You cannot even SAY about a rough consensus until
> it was really broad and open for *anyone*.

Seems that's the way that FreeBSD is constituted, and ultimately it's a 
distribution provided by those who get their hands dirty and do the 
actual work.  More or less.

> Do you have poll results about pkgbase for (by rules of sociology/statistics)
> at least 1500+ votes? No? Then you are just a liar.

How do you make sure the 1500+ votes are representative?
How do you weigh individual votes that are cast?

> Remember, FreeBSD is made for it's USERS. Not for a small group committing
> code to repo.

That is right, but it will work much better for users who constructively 
and concisely describe problems and offer testing effort to get their 
biggest annoyance fixed than by unspecific.

-- 
Matthias Andree