> On Aug 20, 2025, at 6:15 AM, Gleb Popov <[email protected]> wrote:
>
> On Wed, Aug 20, 2025 at 12:48 PM Matteo Riondato <[email protected]> wrote:
>>
>> It’s unclear (to me) whether that’s the *correct* way, or the *recommended*
>> way (pkg(8) calls it “a common idiom”), and in either case *why* is that the
>> recommended/correct way: what breaks if one modifies /etc/FreeBSD.conf ? Why
>> does it break?
>
> The /etc/pkg/FreeBSD.conf file comes from base (some pkgbase package
> or as a result of make installworld or something like that). This
> means that system upgrades must handle edits to this file somehow -
> either by overwriting your changes with vanilla version or by merging
> them, which can't be done 100% automatically.
This is true for so many files under /etc, and we have a solution with
etcupdate (indeed, not 100% automatically, but widely accepted).
> So encouraging users to not touch system configs but rather write
> add-ons to these configs make upgrades less painful.
It seems to me that we don’t have this encouragement with any other files in
/etc.
Why can’t etcupdate handle the changes/updates to FreeBSD.conf?
>> Also, it seems that whether having “repository-name: { enabled: false}”
>> would actually disable respository-name would depend on the order of
>> directories in the configuration variable REPOS_DIR. This feels quite
>> brittle.
>
> This is also a very common problem which has an established solution
> by prefixing config files with numbers, like
> 10-disable-freebsd-repos.conf
No, REPOS_DIR is about _directories_, not files.
Thanks,
Matteo
