Re: PKGBASE Removes FreeBSD Base System Feature

On Sat, Aug 9, 2025, 4:13 AM David G Lawrence <dg@dglawrence.com> wrote:

> > On Sat, 9 Aug 2025 09:08:53 +0200
> > Michal Meloun <mmel@FreeBSD.org> wrote:
> >
> > > On 8/9/2025 8:52 AM, David G Lawrence wrote:
> > > >> On 9 Aug 2025, at 07:29, David Greenman-Lawrence <dg@dglawrence.com>
> wrote:
> > > >>>
> > > >>> FWIW, I do have an opinion on this: I think that "pkg delete -af"
> is
> > > >>> a useful thing that should not destroy your base system. We should
> find
> > > >>> a way to make that work as it always has
> > > >>
> > > >> Today, it will destroy any kernel modules installed from packages,
> including those necessary for the display to work. It will destroy the
> ability for WiFi to work if you???re using wifibox. There are a lot of
> other things in ports that are essential to the system for some systems.
> > > >
> > > >     We can fix that, too. ...but destroying kernel modules doesn't
> mean your
> > > > system doesn't work - it just means X11 won't work when you reboot -
> but then
> > > > it wouldn't anyway because you deleted X11. But, here's the thing:
> X11 didn't
> > > > work when you first installed the base system, either. And perhaps
> your
> > > > Wifi didn't work out of the box, either. So you have some work to do
> to
> > > > get back basic functionality - but you knew that when you did the
> > > > "pkg delete -af" in the first place.
> > > >
> > > > -DG
> > >
> > > I cannot but agree wholeheartedly.. The actual situation with
> > > pkg delete and pkgbase is (for me) simply absurd.
> > >
> > > kmod in the ports is a different problem ??? it shows the inability of
> > > FBSD developers to implement these things on their own,  so this
> > > solution  has some problems.  And don't kill me, I fully understand
> that
> > > it's not possible , but that doesn't change the previous fact.
> > >
> > > Michal
> >
> > Sometimes yes, but sometimes no.
> >
> > On early but widely testable developement phase for drivers, especially
> > SD card drivers, network (including but not limited with WiFi) drivers
> > and disk controllers, base is not a good place even for FreeBSD-native
> > drivers.
> >
> > This is because turnaround time for implememt (fix) / test / commit
> > on base is usually take much longer days (or even months!) than in
> > ports. So recently, AFAIK, some drivers are first developed as
> > kmod ports, and once stabilized, merged into main branch of src.
> >
> > What comes in my mind is rtsx driver for Realtek SD card reader driver.
>
> Tomoaki,
>
>    I see what you're saying and I agree completely. But, I think this is
> pointing squarely at problem in the development paradigm for src
> committers.
> It should not take weeks or months to fix/test/commit/repeat in src. It
> didn't used to be that way, so if it is now, then something has broken
> in the paradigm, and _that_ needs to be fixed.
>

Fun fact: bectl would completely fix the pkg delete issue. But I digress:
rm -rf In the wrong spot also will kill base. It's a strange hill to die
on. It also ignores common use cases, like wifibox, that make a system
critically dependent on ports that in simplwr times didn't happen...

But some perspective on rtsx.  the rtsx driver is an obscure edge case 1000
times less popular than the sdhci driver. And even that is 1000x less
popular than nvme. Given limited time and lack of ability to buy the rtsx
hardware easily, it's hard to justify using my time for that driver when
testing patches for other drivers is easier and benefits more people.
That's why I passed over some of the changes there, especially since there
were big issues with that driver initially that would have taken a lot of
time to articulate. That is how I have prioritized my time on the thousands
of fixes i have done for people, many the same day. Using it as a
posterchild for src being slow overstates the problems typical patches have
gwtting in.

I have been trying to solve the actual, underlying problems behind it:
getting the pipeline flowing better through reduced friction for
submissions (some good, but many lousy and it takes time to sort and you
never know if a lot of feedback will produce a better outcome for any given
problematic patch). Getting a deeper bench onboard and growing aspects of
our culture are also key areas needing help. I've had a hard time getting
others to help, assume ownership, follow through on promises, etc. If you
want to help fix things, it's helping me fix this problem. Fixing that
increases the scarse developer resources and helps make it easier to fix
more issues. But 4 years in, it is a problem resistant to easy solutions.

Warnet

-DG
>
>  *  Dr. David G. Lawrence
> * * DG Labs
>     Pave the road of life with opportunities.
>
>