> Fun fact: bectl would completely fix the pkg delete issue.Does bectl(8)
works with UFS filesystem?I know that this is rhetorical question.If properly
installed FreeBSD can even have UFS Boot Environments:-
https://vermaden.wordpress.com/2021/04/02/ufs-boot-environments/But that is
just workaround for the problem - not a solution.Regards,vermadenTemat: Re:
PKGBASE Removes FreeBSD Base System FeatureData: 2025-08-09 13:17Nadawca:
"Warner Losh" <[email protected]>Adresat: "David G Lawrence"
<[email protected]>; DW: "Tomoaki AOKI"
<[email protected]>; "Michal Meloun" <[email protected]>;
"FreeBSD Current" <[email protected]>; On Sat, Aug 9, 2025,
4:13 AM David G Lawrence <[email protected]> wrote:> On Sat, 9 Aug
2025 09:08:53 +0200 > Michal Meloun <[email protected]> wrote: >
> > On 8/9/2025 8:52 AM, David G Lawrence wrote: > > >> On 9
Aug 2025, at 07:29, David Greenman-Lawrence <[email protected]> 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.
