Re: FreBSD pkgbase MUST be ebandoned

On Tue, 10 Feb 2026 08:25:25 -0800
Adrian Chadd <[email protected]> wrote:

> On Mon, 9 Feb 2026 at 15:35, Poul-Henning Kamp <[email protected]> wrote:
> >
> > --------
> > Vadim Goncharov writes:
> >  
> > > On Mon, 09 Feb 2026 21:20:31 +0000  
> >  
> > > Let me educate you about how human society (and, by consequence,
> > > opensource community), works. It works by a thing called "division of
> > > labor".  
> >
> > And I take it you, Camerat Napoleon, is the chosen one who gets to do the
> > dividing ?
> >
> > Not!
> >
> > If you are so dissatisfied with pkgbase, that you feel it should
> > be "abandonned", you are 100% free to abandon it at any time.
> >
> > But the only way you get to make everybody else abandon pkgbase,
> > is to lure them, with what /they/ find a better alternative.  
> 
> To back up phk@'s point:
> 
> Division of labour works when there's participants to divide labour amongst.
> Open source communities are a mix of paid and unpaid labour.
> We don't force anyone to contribute.
> 
> Given those three constraints, the outcome can only really be:
> 
> * what people can afford to do (time or money wise);

True till this point.

> * what people incrementally collectively decide - with a rough
> consensus - what to work towards;
> * figuring out what said rough consensus is so we can incrementally
> contribute and improve;

The problem is here. I'm participating in IETF activities and I know what
rough consensus is. In fact, it's enough just two voices with strong objections
and this will be no consensus.

For pkgbase, there were no polls even for contributors' votes, while in fact it
should be for broader user masses.

> * people contributing effective labour.
> 
> If you dislike pkgbase then yes, your view is valid. If you find it
> difficult to use (and I do,
> as a developer, find it difficult to use) then yes, your view is
> valid. If you're going to complain

The problem is not just dislike - it is predictable that pkgbase approach will
break things, and it is observed it DOES break things in practice.
So this is not matter of taste, it is *harmful*, like something which forces
system into unbootable state.

> about it (again, like I do, in chats with the other developers) then
> it's on you to figure out
> how to change rough consensus so things can and do move in a direction
> that may make
> you complain less.
> 
> /My/ goal in complaining on it with other developers working on
> pkgbase isn't to tell them
> it sucks, it's to figure out all of the sore/pain points and
> incrementally improve it.

I find the fundamental approach is wrong, so that breaking things is just
inevitable consequence. That is, it is unclear if it can be fixed by
inremental improvements at all. Like trying to secure HTTP incrementally
without TLS (bad metaphor, but still).

> IMHO FreeBSD tends to have developers who have found a flow that works
> for them, and
> it may not work for others. This is the nature of freely contributing
> your labour - you can
> and do choose who, what, where, when and why. No-one's telling you what to
> do.

I remember old good times when developers supported flows working for *all*
users, not just them. This always was (sadly, was!) one of ultimate features of
FreeBSD compared to competitors.

> Figuring out that gap, figuring out how to close that gap, whilst also
> building consensus
> and moving things forward - that's the real trick.

OK, I think I found alternative yet simple approach for base system upgrade.

Observe that, conceptually, the core of any base Unix update process is like:

   # cd /
   # copy-old-shlibs-to-backup-path.sh
   # git checkout -b new-version-X.Y.Z

if binaries were put in some repo, except that no real VCS can do exactly this
in practice. But conceptually, this gives you very easy update, rollback and
hashsum-checking facilities, moreover, it does it efficient way with storing
and downloading just deltas between files! This is something pkg can't do and
is still actual in some regions or some situations.

Interesting here is that freebsd-update, illustrating a law similar to
Greenspun's tenth rule, is an ad hoc, informally-specified, hard to maintain,
slow implementation of half of a version control system. And yes, it has
binary patches!

So possible way to go coould be take some VCS, patch it and compile as
static... but wait, isn't that remindering something?!

Oh, yes, there is net/gitup port, with no dependencies outside base, not
requiring having a .git repo, made exactly for updating some directories from
external FreeBSD repositories!

So effectively what needs to be done here is:
1) add 'ignore' to gitup for being able to operate in specified directories
   only
2) add support of signed commits to gitup
3) make a small wrapper script to run gitup from / for every base system
   component

- and that's all! And it is very easy on FreeBSD cluster's side, or any person
wanting local patched version, to proivide updates - just `git commit` them!

Well, one could say it is not fine-grained. But actually this is a feature,
base system on a physical host is something you want complete and atomic, NOT a
bunch of packages with dependencies when something's missing (I always hate it
on Linuxes, they never have tcpdump or traceroute or something elementary like
that), and one can always tweak src.conf and setup own git repo.

> (And yes, I am not joking. I've been gently trolling/complaining about
> broken stuff in FreeBSD
> in developer chats since I've been back and active. Things don't get
> better when you ignore
> them. :-) )

And ignoring user voices also falls into this category...

-- 
WBR, @nuclight