Re: PKGBASE Removes FreeBSD Base System Feature

On Sat, 9 Aug 2025 04:42:44 -0700
David G Lawrence <dg@dglawrence.com> wrote:

> > > > > 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...

As Vermaden replied to different thread of this topic, his issue
seems to be "in jail". IIUC, he attempted to deinstall everything
installed PkgPkg (in contrast with PkgBase) keeping PkgBase world
in the jail intact, but result was everything including PkgBase
in the jail was deinstalled and made the jail unkillable.
And stating there should be kinda "safety net" for such a case.


> > 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.

Ah, sorry for the confusion.
rtsx is just an example that developements are undergone on ports
and merged into base after it was considered stable.
Not an example for "delays".

IMHO, delays would be because "there are no reviewers having time
and experienced in the area".
In areas that many committers are interested in and experienced,
things goes quickly, except for MFCs.

But in case it's not, for example, smbfs, there is long standing
PR that is NOT yet committed like Bug 90815.

  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=90815

It's already approaching to a decade and I still need the patch.


> > 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.

One thing making difficult to sort out would be "duplicates".
For example, there are tons of "actually duplicated" threads in forums.

IIUC, Bugzilla has functionality to notify/mark any PR as duplicate
once another PR marks it as duplicate of itself (or if marking itself as
a duplicate of another PR, it is shown as dublicate on another).
But IIRC, only the reporter and moderators/admins can mark it.
So whenever I noticed existences of duplicates of any PR I'm looking
into, I comment (yes, comment!) "this would be the duplicate of
Bug xxxxx", as I'm neither admin nor moderator of Bugzilla.


> > Warner
> 
>    ...and for the record, I didn't have any idea about where the problem
> is/was, but now I see it clearly, and I did not intend to critizise anyone.
> I, as well as anyone I think, understand that FreeBSD is a volunteer
> project and any time that a developer puts into it is a _gift_, and we
> must never lose sight of that.

Yes. Unfortunately, it's forgotton quite often.
I'm now working on nvidia-driver and related ports, but I'm not at all
sponsorerd, nor employee of nvidia. 100% volunteer basis.
Recently I'm surprized to hear, at least on some distros, nvidia-driver
is far behind FreeBSD ports.


>    But now I'm going to say something controversial: I was disappointed
> by the reaction about AI, and how it could help the project, in the
> developers list. While I fully appreciate the concerns about "stealing"
> other people's work (indirectly through the training of the vast corpus of
> the Internet) - i.e., the potential to violate copyright, what was said in
> that thread - to dismiss what AI could do for the project, for the
> development cycle - was exceptionally, tragically, myopic. Most people in
> the world (and here I mean 5 Sigma +) have no idea what's about to hit
> them. I've been deep in AI research recently and I can tell you, first
> hand, well...we're in for interesting times ahead. We can either embrace
> it or be tossed into the scrap heap of history.

My opinion about AI-generated codes is that "need to be clarified in
international law about copyrights and licenses first".
But it is, AFAIK, still in discussion at each countries. Not at UN.
This is the fatal problem.

My assumption is "if the operator specifies the license to be
(including possibly to be) applied to the resulting codes,
AI referres only to non-violating knowledges/data/codes and
generate codes" is needed to be implemented by AI guys.

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


-- 
Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>