Re: PKGBASE Removes FreeBSD Base System Feature

I think the .tgz blobs used by NetBSD are a good example of the biggest
blobbyness you want. rescue and base are the minimal safe set. games X11,
debug and documentation are long standing extras.

I also agree with you Werner, that if you have a SAT capable dependency
solver, the finer you go the more likely it is you can come up with a NIX
type formally provably minimally complete set of dependent parts, and
reduce the install surface to a maximum.

I guess I'm kind-of saying in user-experience, I feel a bit in box A and
box B.

For now, I like the direction the intent is going: yes, a lot of parts.
But, separating their "head" so pkg delete -f is "safe" for ordinary use is
a good plan (if that IS the plan)

-G

On Mon, Aug 4, 2025 at 9:22 AM Warner Losh <imp@bsdimp.com> wrote:

>
>
> On Sun, Aug 3, 2025, 4:19 PM Daniel Morante <daniel@morante.net> wrote:
>
>> I just took a look at
>> https://pkg.freebsd.org/FreeBSD:15:amd64/base_latest/ and I am instantly
>> disappointed. I was a fan of the idea, but seeing how they decided to make
>> one package for each item is a massive bummer. Why would you split it up
>> this way? When when you install the Mozilla Firefox via package, you don't
>> install every file individually as a separate package.
>>
>
> But you do install a boatload of related packages...
>
>> It's the same concept for FreeBSD. All these files make up a single
>> entity "FreeBSD" the operating system. Why on earth would you install each
>> item that's required to run FreeBSD as a separate package? All this will do
>> is create increased overhead when installing the system (as each package
>> must go through it's verification and transaction process), and all sorts
>> of trouble down the line when dependency hell sets in.
>>
> If it hasn't set in when a new dependency was free and it's cost hidden,
> chances are we are safe. One big problem wi freebsd in embedded space is
> getting a good subset. Fine grain gives that a fighting chance.
>
> Warner
>
>
>>
> This is not the FreeBSD way.  Very sad, concerned, and disappointed at
>> this design choice.
>> On 7/30/2025 3:30 AM, Baptiste Daroussin wrote:
>>
>> On Wed 30 Jul 02:28, vermaden wrote:
>>
>> Hi,
>>
>> after short discussion here:
>> - https://github.com/freebsd/pkg/issues/2485
>>
>> I got REALLY concerned.
>>
>> One of THE features and selling points of a FreeBSD UNIX system is the 'untouchable' Base System.
>>
>> untouchable is really subjective and has always been, there are so many build
>> options and one of the selling point for many is the customizability, in
>> particular for the wildly deploy use case of appliances.
>>
>> But even on desktops people keeps tweaking the build options...
>>
>> Without PKGBASE all the features are preserved.
>>
>> But when You convert to PKGBASE its ... GONE!
>>
>> Consider this command:
>>
>> # pkg delete -af
>>
>> What it does?
>>
>> It removes all third party packages on 'classic' FreeBSD system without touching the FreeBSD Base System.
>>
>> No it remove all the packages. semantic matters.
>>
>> What the same "pkg delete -af" command does on a PKGBASE FreeBSD system?
>>
>> It kills/destroys almost all of the FreeBSD Base System and leaves only two PKGBASE packages called:
>>
>> - FreeBSD-clibs
>> - FreeBSD-runtime
>>
>> This is why the vital flag are designed for.
>>
>> All the rest of Base System is GONE. Destroyed.
>>
>> You do not even have vi(1) editor ad /rescue is separate not protected FreeBSD-rescue package and its also removed.
>>
>> WTF?!
>>
>> POLA is the principle that made FreeBSD such predictable system. Where is the POLA now?
>>
>> Why the same *pkg delete -af* command on 'classic' FreeBSD system without PKGBASE only removes all third party packages and the same *pkg delete -af* literally destroys most of the FreeBSD PKGBASE Base System?
>>
>> Its crazy ...
>>
>> Before jumping straight into making a drama, maybe ask for the plan? or discuss
>> with people involved, or even better propose some help?
>>
>> The plan is the following for years: either create meta packages which will be
>> flagged as vital for various combinaison of pkgbase: base, base-minimal,
>> base-oci etc., etc. and use groups (marked as vital as well) if they are ready
>> by then. This part has been delayed because: groups are now ready yet in pkg but
>> might be there by the time 15.0-RELEASE is there.
>>
>> Bapt
>>
>>
>>