Re: RFC: Renaming "FreeBSD" repo in /etc/pkg/FreeBSD.conf to "FreeBSD-ports"
- In reply to: Gleb Popov : "Re: RFC: Renaming "FreeBSD" repo in /etc/pkg/FreeBSD.conf to "FreeBSD-ports""
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 20 Aug 2025 12:26:29 UTC
> On Aug 20, 2025, at 7:03 AM, Gleb Popov <arrowd@freebsd.org> wrote: > > On Wed, Aug 20, 2025 at 1:20 PM Matteo Riondato <matteo@freebsd.org> wrote: >> >>> On Aug 20, 2025, at 6:15 AM, Gleb Popov <arrowd@freebsd.org> wrote: >>> >>> On Wed, Aug 20, 2025 at 12:48 PM Matteo Riondato <matteo@freebsd.org> 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). > > There is no etcupdate involved with binary package upgrades. But there > is still a 3-way merge, yes, but like you said, it is not 100% > automatic. So why not avoid the possibility of a merge conflict if we > can do that? I see that point, and in general it’s a good goal. I would be way more comfortable with the idea that the contents of /etc/pkg/FreeBSD.conf should not be changed if the file lived in /etc/defaults (e.g., /etc/defaults/FreeBSD-pkg.conf or FreeBSD-repos.conf), or had some “default” in its name/path (e.g., /etc/pkg/FreeBSD-repos-defaults.conf (but I would prefer /etc/defaults/FreeBSD-repos.conf)). Thanks, Matteo