Trying to understand base system packages

[Sad Clouds]

Hi I'm trying to understand the new workflows associated with base
packages on FreeBSD-15. I'd like to ask some questions:

1. Does "pkg upgrade" now upgrade both base and ports packages? If yes
then what is the best way to override it and specify explicitly either
base or ports? Is this the correct approach:
# pkg upgrade -r FreeBSD-ports

2. Does "pkg upgrade" for base packages also merge etc files, or do I
need to manually execute etcupdate? Looks like various etc files are
split across different base packages. Is etcupdate even relevant
anymore for upgrades? How does pkg handle merges for locally modified
etc files?

3. In /etc/pkg/FreeBSD.conf FreeBSD-base is disabled by default. What
is the reason for that? Do I need to manually enable it if I want
"pkg upgrade" to upgrade base packages in the future?

4. Why am I not able to delete individual base packages:
# pkg info | grep sendmail
FreeBSD-libmilter-15.0 sendmail Mail Filter API library
FreeBSD-libmilter-dev-15.0 sendmail Mail Filter API library (development files)
FreeBSD-sendmail-15.0 sendmail mail transport agent

# pkg delete FreeBSD-sendmail
Cannot solve problem using SAT solver, trying another plan
Cannot solve problem using SAT solver, trying another plan
Cannot solve problem using SAT solver, trying another plan
Checking integrity... done (0 conflicting)
1 packages requested for removal: 0 locked, 1 missing

5. When building from source and executing "make release" this creates
the traditional *.txz files. In addition to these, how do I also
generate all of the base packages as part of the release? There is
release/pkgbase-repo directory that gets created but it is left empty.
Is running "make packages" a prerequisite before "make release" for
this to happen, or is there a different release target for base
packages?

6. If I need to modify src.conf and build my own set of base packages,
what is the recommended way to install/upgrade with these packages?
Can I tell pkg to fetch the packages from a local directory? The
pkg(8) command supports options like -c (chroot dir), -r (root dir),
etc, but I'm confused on how it should be used. For example:

I build a release for arm64/aarch64 on amd64, create a partition on
microSD card and mount it under /mnt. I then execute
"tar -C /mnt -xpUf base.txz" to install the base system.

How do I replicate the above with pkg? Can anyone provide a quick
example?

Thanks.

[Marco Moock]

On 05.12.2025 12:28 Sad Clouds <cryintot...@gmail.com> wrote:

> 3. In /etc/pkg/FreeBSD.conf FreeBSD-base is disabled by default. What
> is the reason for that? Do I need to manually enable it if I want
> "pkg upgrade" to upgrade base packages in the future?

Is your system already pkg-basified?
What about configuration files in /usr/local/pkg

> 4. Why am I not able to delete individual base packages:
> # pkg info | grep sendmail
> FreeBSD-libmilter-15.0 sendmail Mail Filter API library
> FreeBSD-libmilter-dev-15.0 sendmail Mail Filter API library
> (development files) FreeBSD-sendmail-15.0 sendmail mail
> transport agent
>
> # pkg delete FreeBSD-sendmail
> Cannot solve problem using SAT solver, trying another plan
> Cannot solve problem using SAT solver, trying another plan
> Cannot solve problem using SAT solver, trying another plan
> Checking integrity... done (0 conflicting)
> 1 packages requested for removal: 0 locked, 1 missing

The MTA selection is being done with /etc/mail/mailer.conf
I assume it is not intended to delete the actual software, as it is
part of the base system.


--
kind regards
Marco

Send spam to abfall17...@stinkedores.dorfdsl.de

[Sad Clouds]

On Fri, 5 Dec 2025 13:45:10 +0100
Marco Moock <m...@dorfdsl.de> wrote:

> On 05.12.2025 12:28 Sad Clouds <cryintot...@gmail.com> wrote:
>
> > 3. In /etc/pkg/FreeBSD.conf FreeBSD-base is disabled by default. What
> > is the reason for that? Do I need to manually enable it if I want
> > "pkg upgrade" to upgrade base packages in the future?
>
> Is your system already pkg-basified?
> What about configuration files in /usr/local/pkg
>

In this case, it's new install of FreeBSD-15.0 with base packages.
It's a test VM as I'm just trying to experiment with pkg and understand
the reasons for various settings.

[Sad Clouds]

On Fri, 5 Dec 2025 13:45:10 +0100
Marco Moock <m...@dorfdsl.de> wrote:

> > # pkg delete FreeBSD-sendmail
> > Cannot solve problem using SAT solver, trying another plan
> > Cannot solve problem using SAT solver, trying another plan
> > Cannot solve problem using SAT solver, trying another plan
> > Checking integrity... done (0 conflicting)
> > 1 packages requested for removal: 0 locked, 1 missing
>
> The MTA selection is being done with /etc/mail/mailer.conf
> I assume it is not intended to delete the actual software, as it is
> part of the base system.
>

This happens for every other base package:

# pkg delete FreeBSD-games

[infoomatic]

This is because you have installed certain FreeBSD sets, which are meta
packages. I do admit that the messages from pkg should be improved.

If you want to know what FreeBSD-set-* pulls in FreeBSD-sendmail as a
dependency, use "pkg info -r FreeBSD-sendmail", and then uninstall the
set. You can then uninstall FreeBSD-sendmail.

On my VM which I dedicated to understanding pkgbase, I only have
FreeBSD-set-minimal-jail and FreeBSD-set-kernels installed.

"man freebsd-base" also helps.

hth,

Robert

[Graham Perrin]

On 05/12/2025 14:31, Sad Clouds wrote:
> …

>
> This happens for every other base package:
>
> # pkg delete FreeBSD-games
> Cannot solve problem using SAT solver, trying another plan
> Cannot solve problem using SAT solver, trying another plan
> Cannot solve problem using SAT solver, trying another plan
> Checking integrity... done (0 conflicting)
> 1 packages requested for removal: 0 locked, 1 missing

the error message when removing a dependency of a vital package is
uninformative · Issue #2517 · freebsd/pkg
<https://github.com/freebsd/pkg/issues/2517>

[Sad Clouds]

Hi, thanks for the link. I've read all the comments there and this
still leaves casual FreeBSD users like myself confused. I appreciate
that this feature may still be experimental, however so far I have not
been able not find a way to resolve my original issue.

- I don't understand the design of base meta packages (sets?) and there
is no documentation that describes this well. The freebsd-base(7)
mentions briefly that some packages are grouped into sets, but does not
go deeper, does not explain about the "vital" dependency flag and does
not provide examples of how to view and manage packages sets. In fact
the pkg(8) man page is missing the new "sets" command.

- I'm still stuck with a system where I cannot delete individual
packages which I do not need. The issue seems to be: some package
somewhere is marked as "vital" in the dependency chain, hence pkg
refuses to remove a package. I am still no closer to figuring out how
to resolve this. The comments in the bug suggest "remove the optional
set (this does not remove any other packages)"

Ok, lets try this:

# pkg delete FreeBSD-set-optional

Checking integrity... done (0 conflicting)

The following package(s) are locked or vital and may not be removed:

FreeBSD-set-optional

1 packages requested for removal: 1 locked, 0 missing

I guess there is "-f" option I could try, but I don't like using any
force options, as it usually indicates something is broken somewhere.

I'm sorry but the optional meta package and sendmail (which is part of
it) are not vital and there needs to be an easier way to remove them.
Isn't this the whole point of having base packages, so that the system
can be customised much easier by installing/removing individual
packages, instead of building custom release with custom src.conf
options for different use cases?

# pkg sets
FreeBSD-set-base-15.0:
FreeBSD-set-optional-15.0
FreeBSD-set-minimal-15.0
FreeBSD-set-devel-15.0
FreeBSD-set-devel-15.0:
...
FreeBSD-set-minimal-15.0:
...
FreeBSD-set-optional-15.0:
...

The base set includes all other sets, why? If some meta package is
optional or development software, why is it locked to the base set?

If I misunderstand anything here, then please correct me.

[Lexi Winter]

Sad Clouds wrote in <20251207081139.7e2f...@gmail.com>:
> - I don't understand the design of base meta packages (sets?) and there
> is no documentation that describes this well. The freebsd-base(7)
> mentions briefly that some packages are grouped into sets, but does not
> go deeper, does not explain about the "vital" dependency flag and does
> not provide examples of how to view and manage packages sets. In fact
> the pkg(8) man page is missing the new "sets" command.

there is no "sets" command.

you're right, this is not well documented. i was hoping someone would
write Handbook content for this before release, but no one did, and i
did not have time to do it myself.

fwiw, we expect to replace these metapackages with proper package groups
once pkg supports this; pkg developers are currently working on this.

> - I'm still stuck with a system where I cannot delete individual
> packages which I do not need.

the procedure to remove a package which is part of an installed set is:

- remove the installed set using pkg delete -f

- mark all packages which were previously part of the set as manually
installed, using pkg set -A0. (you may check "pkg autoremove" to see
which packages need to be modified). this is to ensure that pkg
doesn't unexpected autoremove these packages later.

- remove the packages you actually want to remove, without using -f.
(if you need -f here, something went wrong in a previous step.)

> I'm sorry but the optional meta package and sendmail (which is part of
> it) are not vital and there needs to be an easier way to remove them.
> Isn't this the whole point of having base packages, so that the system
> can be customised much easier by installing/removing individual
> packages, instead of building custom release with custom src.conf
> options for different use cases?

yes, this is precisely the point of pkgbase. however, pkgbase in 15.0
is shipped as a tech preview, and there are several features and edge
cases which do not work as well as we would like.

> The base set includes all other sets, why?

because the base set means "the entire base system", which implies that
it also installs all other sets. if you do not want to install "the
entire base system", you should remove (or not install) the base set.

[Lexi Winter]

Sad Clouds wrote in <20251205122830.cb88...@gmail.com>:
> 1. Does "pkg upgrade" now upgrade both base and ports packages?

yes.

> If yes then what is the best way to override it and specify explicitly
> either base or ports?

use the -r flag to pkg upgrade.

> Is this the correct approach:
> # pkg upgrade -r FreeBSD-ports

yes.

> 2. Does "pkg upgrade" for base packages also merge etc files

yes, it will attempt a three-way merge. if this fails, it will print
"pkg: Impossible to merge /etc/somefile" during the upgrade, and you
need to merge the file manually. this message is very easy to miss, so
i suggest that after every upgrade, you search the entire filesystem for
files named '*.pkgsave' or '*.pkgnew'.

we intend to improve this UX in a later release.

> or do I need to manually execute etcupdate?

never run etcupdate on a pkgbase system.

> 3. In /etc/pkg/FreeBSD.conf FreeBSD-base is disabled by default. What
> is the reason for that?

because we don't want to enable this repository for non-pkgbase users.
the installer enables the repository in /usr/local/etc/pkg/repos for
pkgbase installs.

> Do I need to manually enable it if I want "pkg upgrade" to upgrade
> base packages in the future?

no, because the installer does this for you.

> 5. When building from source and executing "make release" this creates
> the traditional *.txz files. In addition to these, how do I also
> generate all of the base packages as part of the release?

"make -C release disc1.iso" will generate the pkgbase repository for the
installer media.

if you only want to generate packages, not release media, then use
"make update-packages". you may want to set REPODIR before running
this; see build(7).

> There is release/pkgbase-repo directory that gets created but it is
> left empty.

this will not be empty if you build a release media that includes
packages. note that bootonly does not include packages.

> Is running "make packages" a prerequisite before "make release" for
> this to happen

no.

> or is there a different release target for base packages?

no.

> 6. If I need to modify src.conf and build my own set of base packages,
> what is the recommended way to install/upgrade with these packages?

use "pkg install" to install them.

if upgrading a system installed from packages which used a different
src.conf, and you did not update the package version, you may need
"pkg upgrade -f" to replace the existing packages.

> Can I tell pkg to fetch the packages from a local directory?

yes:

FreeBSD-base: {
url: "file:///build/packages/base/${ABI}/latest",
enabled: yes

}

> The pkg(8) command supports options like -c (chroot dir), -r (root
> dir), etc, but I'm confused on how it should be used. For example:
>
> I build a release for arm64/aarch64 on amd64, create a partition on
> microSD card and mount it under /mnt. I then execute
> "tar -C /mnt -xpUf base.txz" to install the base system.
>
> How do I replicate the above with pkg? Can anyone provide a quick
> example?

pkg -r /mnt install FreeBSD-set-minimal

[Johan Helsingius]

On 10/12/2025 9:35 am, Lexi Winter wrote:

> yes, it will attempt a three-way merge. if this fails, it will print
> "pkg: Impossible to merge /etc/somefile" during the upgrade, and you
> need to merge the file manually. this message is very easy to miss, so
> i suggest that after every upgrade, you search the entire filesystem for
> files named '*.pkgsave' or '*.pkgnew'.

Seeing this, I thought "oh well, might as well check on my system", and
found a bunch of *.pkgsave files, mostly in /usr/local/bin/, but also
some in /usr/local/share/licenses/. They are all from 2021, so I
probably don't need to worry?

Julf

[Lexi Winter]

Johan Helsingius wrote in <642e4308-3167-45b6...@Julf.com>:

if these are in /usr/local they are not related to pkgbase.

the pkg three-way merge is never performed for ports packages, because
ports are not allowed to install configuration files. (instead, they
install @sample files which are only copied to the real location if they
don't already exist.)

they are also not related to normal ports upgrades, since ports upgrades
can never generate these files.

i'm not sure how you ended up with these files, but some possibilities:

- you manually installed some software that you also installed from
ports, and they installed files in the same place.

- some sort of pkg or ports bug that caused files to be installed
without being registered in pkg. this should be impossible if you
build ports with poudriere, but it's at least plausible that some
sort of bug like this could exist in non-jailed builds.

if they have not been modified for four years, you are probably safe to
delete them.

[Johan Helsingius]

On 10/12/2025 11:33 am, Lexi Winter wrote:
> i'm not sure how you ended up with these files, but some possibilities:
>
> - you manually installed some software that you also installed from
> ports, and they installed files in the same place.

That is quite possible.

> if they have not been modified for four years, you are probably safe to
> delete them.

Thanks for confirming my assumption!

Julf

[Sad Clouds]

On Wed, 10 Dec 2025 08:28:18 +0000
Lexi Winter <i...@freebsd.org> wrote:

> Sad Clouds wrote in <20251207081139.7e2f...@gmail.com>:
> > - I don't understand the design of base meta packages (sets?) and there
> > is no documentation that describes this well. The freebsd-base(7)
> > mentions briefly that some packages are grouped into sets, but does not
> > go deeper, does not explain about the "vital" dependency flag and does
> > not provide examples of how to view and manage packages sets. In fact
> > the pkg(8) man page is missing the new "sets" command.
>
> there is no "sets" command.

Hmm, that's not what I see:

# pkg sets
FreeBSD-set-base-15.0:
FreeBSD-set-optional-15.0
FreeBSD-set-minimal-15.0
FreeBSD-set-devel-15.0

... etc.

Maybe it was implemented as an undocumented developer/debug option and
people forgot to remove it? But then if the concept of package sets is
going to be superseded by package groups, then this may explain it.

[Kurt Hackenberg]

On Wed, Dec 10, 2025 at 08:28:18AM +0000, Lexi Winter wrote:

>you're right, this is not well documented. i was hoping someone would
>write Handbook content for this before release, but no one did, and i
>did not have time to do it myself.

So how can we know how to use it? Read the entire archive of the
mailing list? Read the source code?

A one-page description of the basic overall design would be a lot
better than nothing.

>however, pkgbase in 15.0 is shipped as a tech preview, and there are
>several features and edge cases which do not work as well as we would
>like.

Maybe we shouldn't use it in 15.0. How can we know how to avoid it?

[Dag-Erling Smørgrav]

Sad Clouds <cryintot...@gmail.com> writes:
> Lexi Winter <i...@freebsd.org> writes:

> > Sad Clouds <cryintot...@gmail.com> writes:
> > > In fact the pkg(8) man page is missing the new "sets" command.
> > there is no "sets" command.
> Hmm, that's not what I see:

There is no sets command. Type `pkg help sets` and you will understand.

DES
--
Dag-Erling Smørgrav - d...@FreeBSD.org

[Sad Clouds]

$ pkg help sets
`sets` is an alias to `info -d -C -x '^FreeBSD-set-'`

OK thanks for the clarification. So it's an internal alias that
masquerades like a pkg command.

[Sad Clouds]

On Wed, 10 Dec 2025 13:23:21 -0500
Kurt Hackenberg <k...@panix.com> wrote:

> >however, pkgbase in 15.0 is shipped as a tech preview, and there are
> >several features and edge cases which do not work as well as we would
> >like.
>
> Maybe we shouldn't use it in 15.0. How can we know how to avoid it?
>

I assumed that the "technology preview" meant: "the feature is fully
complete and ready to use, but may contain minor bugs".

The fact that it is still undergoing development and design changes,
suggests that the feature is still work in progress. Some may
disagree with this definition. Anyway, I think this is fine and helps
to get test exposure from different users. If you are someone like me
who uses FreeBSD occasionally and not too deeply familiar with its
sysadmin features, then may be avoid using base packages on production
systems.

[Dag-Erling Smørgrav]

Sad Clouds <cryintot...@gmail.com> writes:

> Dag-Erling Smørgrav <d...@FreeBSD.org> writes:
> > There is no sets command. Type `pkg help sets` and you will
> > understand.

> OK thanks for the clarification. So it's an internal alias that
> masquerades like a pkg command.

I don't know what you mean by “internal alias” or “masquerading”. It's
an alias, which is a well-documented feature of pkg. Those of us whose
machines have been upgraded incrementally for years or decades don't
have it because it's a relatively recent addition and upgrading pkg does
not update pkg.conf, where aliases are defined. If you want to know
what it does, you type `pkg help sets`, see that it is an alias for `pkg
info` with some arguments, and type `pkg help info` to learn what those
arguments mean.

[Graham Perrin]

On 10/12/2025 08:28, Lexi Winter wrote:
> … the base set means "the entire base system", which implies that

> it also installs all other sets. if you do not want to install "the
> entire base system", you should remove (or not install) the base set.

For (at least) 15.0, I should never recommend omitting the
FreeBSD-set-base meta package.

Beware of <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291034>.

From <https://mastodon.bsd.cafe/@grahamperrin/115672864923297476>:

> In plain English: you can choose a United Kingdom keyboard layout, the
> end result is US.

----

Also, "base" has multiple meanings.

[Graham Perrin]

On 10/12/2025 08:35, Lexi Winter wrote:

> … the installer enables the repository in /usr/local/etc/pkg/repos for
> pkgbase installs. …


<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291502>
Documentation should not advise users to overwrite
/usr/local/etc/pkg/repos/FreeBSD.conf


From the preceding report, 291501:

> Overwriting the file will cause the operator to not gain updates to base.


sysutils/desktop-installer uses a separate file for people who switch
from quarterly to latest for the two ports repositories,

/usr/local/etc/pkg/repos/bleeding-edge.conf

[Lexi Winter]

Sad Clouds wrote in <20251210203319.c248...@gmail.com>:
> I assumed that the "technology preview" meant: "the feature is fully
> complete and ready to use, but may contain minor bugs".
>
> The fact that it is still undergoing development and design changes,
> suggests that the feature is still work in progress.

the entire FreeBSD system is "still undergoing development and design
changes", yet we still ship releases every year. also, "the feature
is fully complete and ready to use, but may contain minor bugs" is a
description of FreeBSD as a whole. basically, what you're describing
is a production software release: we think this is ready, but it may
contain some bugs (which is why we have errata).

the reason pkgbase is described explicitly as a tech preview is that we
*know* it's missing support for less common, yet important use cases[0],
but at the same time:

- it offers clear advantages for many users, despite having some rough
edges, so there is a user benefit to providing it for people who want
to use it;

- we are at the point where we need feedback from actual users to
inform future development, and a tech preview is a good way to
achieve that.

[0] along with at least one major issue, which is the way sets are
managed; unfortunately, for various reasons we didn't realise
sets would be required until very late in the development cycle,
so there wasn't time to work out all the pkg bugs before release.

[Sad Clouds]

I'm thinking more about the command behavior rather than just being
aware that something is an alias. Hence:

"Internal alias" refers to pkg internal functionality to create
command aliases, rather than shell aliases, etc.

"Masquerading" refers to pkg (via a "sets" alias) giving an illusion of
a dedicated command to view the base sets. However since it is not a
dedicated command, it may have unwanted side effects, for example if
someone creates a third party package which starts with "FreeBSD-set-"
string, then "pkg sets" may list that package as well, creating
confusion.

I'm not criticising pkg command or the decision to adopt it for the base
packages. I understand the benefits of code reuse and familiarity for
the existing users. However I personally think that a dedicated syspkg
tool with a completely separate implementation could be a better design
strategy.

But then as a software developer myself I know that it is much easier to
criticise someone's efforts and much harder to roll up your sleeves the
write the code yourself. I'm grateful to the FreeBSD community for
their efforts and politely answering questions on this mailing list.

[Sad Clouds]

On Thu, 11 Dec 2025 00:22:30 +0000
Lexi Winter <i...@freebsd.org> wrote:

> the entire FreeBSD system is "still undergoing development and design
> changes", yet we still ship releases every year.

There are many different software development processes and I guess each
one has its pros and cons. I personally prefer the traditional software
life cycle: requirements, design, implementation, testing, deployment.

The advantage is that you are less likely to release half-baked
solutions and any issues found during implementation or testing can be
pushed back to the re-design stage without exposing any of the mess to
the end users. So for me "production software" means: all aspects of
the requirements + design + implementation are complete, documentation
is complete, and all unit and integration tests are complete and we have
close to 100% test coverage.

There is nothing wrong with the iterative process and many projects
take this approach. However I used to work in a commercial software
development environment and had a really bad experience with the Agile
process that was forced upon everyone in the company.

People were "harassed" by clueless managers to release some feature
every two weeks and we often released buggy and half-baked software,
which was poorly tested and lacked extensive documentation. Part of the
problem was that some complex features took 6 months or more to
implement and were difficult to fully implement and verify in smaller
parts because of the various inter dependencies.

[Dag-Erling Smørgrav]

Sad Clouds <cryintot...@gmail.com> writes:
> There are many different software development processes and I guess each
> one has its pros and cons. I personally prefer the traditional software
> life cycle: requirements, design, implementation, testing, deployment.

This has been conclusively shown to be the worst possible way to develop
software and is therefore rarely used unless imposed by regulators or
underwriters. And it has never been how F/OSS worked.

[Sad Clouds]

Well I think that is a bit of an overgeneralisation and the choice of a
software development methodology depends on various factors. I would
not consider the open source software to be the pinnacle of software
development excellence. The fact that large parts of it are still
written in C and C++ speaks volumes about the developers' priorities.

Safety-critical software will have a much more formal and
structured software life cycle compared to other sectors. If you place
more emphasis on software reliability and maintainability rather than
the development speed, then the Waterfall or V-Model methodology would
be more appropriate.

The "move fast and break things" philosophy that permeates through many
commercial and open source projects does not sit too well with me. But
that is my personal opinion, and others are entitled to theirs.

[Dag-Erling Smørgrav]

Sad Clouds <cryintot...@gmail.com> writes:
> Safety-critical software will have a much more formal and structured
> software life cycle compared to other sectors. If you place more
> emphasis on software reliability and maintainability rather than the
> development speed, then the Waterfall or V-Model methodology would be
> more appropriate.

I've worked in the functional safety field. These systems are developed
using the waterfall model not because it works but because underwriters
require certification and certification bodies are centuries-old
organizations with deep roots in civil and mechanical engineering that
simply don't understand software. The result is software that has just
as many bugs but takes ten times longer to develop and doesn't actually
meet its users' needs. The only tangible benefit is better
documentation.

> The "move fast and break things" philosophy that permeates through many
> commercial and open source projects does not sit too well with me. But
> that is my personal opinion, and others are entitled to theirs.

You are barking up the wrong tree; “move fast and break things” is a
business strategy, not a development methodology.

[Sad Clouds]

On Thu, 11 Dec 2025 13:15:06 +0100
Dag-Erling Smørgrav <d...@FreeBSD.org> wrote:

> simply don't understand software. The result is software that has just
> as many bugs but takes ten times longer to develop and doesn't actually
> meet its users' needs. The only tangible benefit is better
> documentation.

OK I respect your views, however based on your experience, which
software methodology would you employ for your own projects? And let's
assume these are complex projects which can take 12 months to complete
and you have complete freedom to make your own decisions on everything.

> You are barking up the wrong tree; “move fast and break things” is a
> business strategy, not a development methodology.

Well, I referred to it as a "philosophy" which can imply a number of
things, including software development approaches. How it was
originally coined by Facebook in somewhat irrelevant.

[Paul Mather]

Back in 2016 I posted to the freebsd-arm mailing list about moving to using pkgbase to update my FreeBSD/arm systems because it was too onerous to update them via the traditional src cross-building method. (https://lists.freebsd.org/pipermail/freebsd-arm/2016-July/014444.html) That was back on FreeBSD 11, where pkgbase was still a work-in-progress yet to see any official release.

I am very grateful that the powers that be decided finally to provide pkgbase as a technology preview for the recent FreeBSD 15.0-RELEASE, because I believe it will bring more development focus and testing to this important feature. I applaud the decision to make this an optional technology preview for 15, with the understanding it will become default for 16. Given the long gestation, it's a relief to see an official release finally supporting it in the installer and official repositories as a mainstream option. The recent flurry of activity surrounding pkgbase and pkg itself shows that committing to a feature can really focus developer activity. Kudos to all those who have worked on this for the 15.0-RELEASE.

I also appreciate this has been released as an opt-in feature for 15. I chose to select it for a fresh install on a new desktop system I was deploying, and it has been working wonderfully so far. For other servers and jails that were running FreeBSD 14, I decided to upgrade them to 15 using the existing src-based {build,install}{kernel,world} method I'd always used. That approach worked fine for me, too. Choices are a good thing. :-)

I figure with the wider testing afforded by the FreeBSD 15 technology preview that the remaining kinks should get worked out at a faster rate for 16, when it becomes the default. The pragmatist in me suspects that without seeing an official release, it may have continued to languish as an "upcoming feature."

Cheers,

Paul.

[Sad Clouds]

On Wed, 10 Dec 2025 08:28:18 +0000
Lexi Winter <i...@freebsd.org> wrote:

> > The base set includes all other sets, why?
>
> because the base set means "the entire base system", which implies that
> it also installs all other sets. if you do not want to install "the
> entire base system", you should remove (or not install) the base set.

Hi, can you please confirm if this is a pkg bug, or if I did something
stupid.

# pkg info | grep metapackage

Then for each metapackage I executed:

# pkg delete -f FreeBSD-set-XXX

This removed all sets, including base. The individual packages are
still there. I did not touch them.

If I now attempt to run "pkg autoremove" to see which packages need to
be marked manually installed, pkg goes into infinite loop, gradually
consuming memory at a rate of 1 MiB every 5 seconds.

[Lexi Winter]

Sad Clouds wrote in <20251211152822.d5d3...@gmail.com>:
> # pkg info | grep metapackage
>
> Then for each metapackage I executed:
>
> # pkg delete -f FreeBSD-set-XXX
>
> This removed all sets, including base. The individual packages are
> still there. I did not touch them.
>
> If I now attempt to run "pkg autoremove" to see which packages need to
> be marked manually installed, pkg goes into infinite loop, gradually
> consuming memory at a rate of 1 MiB every 5 seconds.

this sounds like a pkg bug (it is certainly not intentional behaviour),
which you can report at <https://github.com/freebsd/pkg>. i suggest
saving a copy of /var/db/pkg from the affected system, as this might
be important to diagnose the issue.

[Dag-Erling Smørgrav]

Sad Clouds <cryintot...@gmail.com> writes:
> OK I respect your views, however based on your experience, which
> software methodology would you employ for your own projects? And
> let's assume these are complex projects which can take 12 months to
> complete and you have complete freedom to make your own decisions on
> everything.

Some variation on Agile, which as Poul-Henning Kamp once pointed out is
merely a codification of how F/OSS has always done things. It depends
on the size of the team and the relationship with the stakeholders. And
yes, like you, I've seen Agile done very, very badly, but I don't blame
the method (which has worked well for me) for the shortcomings of the
people involved.

(I've had to work with a team whose manager constantly demanded detailed
documentation for my components while refusing to provide any for their
own because “Agile means no documentation”. He also refused to let me
speak to his developers because “Agile means I shield my team from
distractions” or even relay my questions to them. I eventually cut the
Gordian knot by “accidentally” running into his team at lunch.)

Note that Agile does not mean you don't write specifications or tests or
documentation. It just means you do it repeatedly and continuously and
incorporate the lessons you learn from one iteration into your plans for
the next.

[Sad Clouds]

https://github.com/freebsd/pkg/issues/2571

I'll keep the VM in this state for now in case anyone needs more info.

[Sad Clouds]

On Thu, 11 Dec 2025 18:17:44 +0100
Dag-Erling Smørgrav <d...@FreeBSD.org> wrote:


> Some variation on Agile, which as Poul-Henning Kamp once pointed out is
> merely a codification of how F/OSS has always done things. It depends
> on the size of the team and the relationship with the stakeholders. And
> yes, like you, I've seen Agile done very, very badly, but I don't blame
> the method (which has worked well for me) for the shortcomings of the
> people involved.

OK, if it works for you and your team then happy days. I spent around
10 years doing some variation on Agile (if you can call it that) and
disliked everything about it. Luckily I left the company years ago and
no longer have to be tormented by pointless sprint planning,
retrospective and daily stand up meetings.

The company spent a fortune on hiring dedicated Agile scrum masters,
consultants and organising various training sessions for all of us.
I've lost count of how many times I heard "Agile is great, you are just
not doing it right". We had the best consultants and training that the
money could buy and I don't think the Agile process helped us to
deliver better software quality. In fact, it made the development
slower, more painful and unpleasant, since people became obsessed with
the process and the user stories and the various metrics like velocity
and burndown, etc.

There are specific software development practices that you apply in
different situations. Some may call for a complete and formal
requirements specification upfront, some my call for test driven
development, etc, everything else that the Agile brings with it is
just BS in my humble opinion.

What is more important are the people around you, the knowledge and
experience they have and the motivation they generate within a team.
I've seen how micromanagement, incompetence and narcissism can destroy
peoples' motivation and confidence. No amount of Agile or some other
magic process is going to help here.

[Mathias M.]

On Thu, Dec 11, 2025 at 12:22:30AM +0000, Lexi Winter wrote:
>
> - it offers clear advantages for many users, despite having some rough
> edges, so there is a user benefit to providing it for people who want
> to use it;
>

As a random, long time FreeBSD user:
Those 'advantages' elude me and are anything but clear.

But maybe that's just me, so y'all keep working on it and eventually
I'll get it, when things take shape later down the road.

Regards,
Mathias
--
"Do you smell something burning or is it me?"
-- Joan of Arc

[Edward Sanford Sutton, III]

On 2/11/26 02:40, Mathias M. wrote:
> On Thu, Dec 11, 2025 at 12:22:30AM +0000, Lexi Winter wrote:
>>
>> - it offers clear advantages for many users, despite having some rough
>> edges, so there is a user benefit to providing it for people who want
>> to use it;
>>
>
> As a random, long time FreeBSD user:
> Those 'advantages' elude me and are anything but clear.

A package manager keeps track of what to install and later to
uninstall. Before that, freebsd-update and (my main
experience/knowledge) source updates use a set of handcrafted tools to
try to manually remove content that no longer exists because it has been
removed or comes from an option that was disabled for the current build.
Some of those steps have a catch in that if you go too long since its
last cleanup then what it should clean out has been removed from the
list so will be leftover debris which may or may not impact how the
system currently runs. Without a source install, its just a tarball used
to install it but no records are kept for future reference of what was
put in by that extraction or any other steps.
In my opinion the build system's `make delete-old` and similar in my
opinion should have a complete list that is not pruned available even if
it is slower to run. It could be written to be a sequential list that
optionally, but by default, aborts further cleanup steps once something
is no longer present when trying to clean it or it could use 1+ files to
keep track of previously completed cleanup steps to skip ones that are
completed though I'd see the 1+ extra files as likely unneeded bloat by
comparison but it allows for a more reliable cleanup stage without
having to fall back to a full cleanup.
The package manager controlling it means its tracked by a system
designed to track it so uninstall is an actual operation with a better
controlled and tracked outcome. It also opens the door for optional
things to be easily excluded/removed without requiring a rebuild.
One thing I consider a disadvantage if I understand it correctly is
pkg upgrades by doing a full removal + reinstall so anytime a small
change happens for what is covered by a package then it is a larger
operation than should be necessary to download and replace what actually
changed. I'm not sure how much that happens with freebsd-update but
source installs seem to be a full rewrite unless you run it in pieces
and not `make -C /usr/src installworld` or its installkernel operation.
I consider that a limitation of pkg itself and hope that too can change
in the future which will accelerate almost all upgrades and minimize
disk wear for better life on low quality storage devices without
requiring a workaround like ZFS's dedup.
I'm not sure how the other options compare regarding handling dealing
with interrupted/failed updates but from source you can always start
over the install to get back to an expected state as long as you can
boot the system (even from separate media) and can access the build
environment + install destination.

[Graham Perrin]

On 11/02/2026 09:40, Mathias M. wrote:
>> …

> As a random, long time FreeBSD user:
> Those 'advantages' elude me and are anything but clear.
>

> But maybe that's just me, …


It's not just you :-)

Traditional freebsd-update is not compatible with STABLE or CURRENT.

base packages are not so limited. They exist for 14 RELEASE, 14 STABLE,
15 RELEASE, 15 STABLE, and 16.0-CURRENT.

With traditional/legacy distribution sets (tar archives): it's
relatively difficult to reinstall the OS.

With base packages: it's relatively easy to reinstall.

<https://freebsdfoundation.org/blog/freebsd-15-why-youll-want-it/> lists
four bullet points, one of which is about STABLE and CURRENT, and
"… more flexibility in keeping systems minimal, consistent, and up to
date.".

Advantages exist, but are not well-documented.