| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 23 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 46:56:43 |
| Calls: | 583 |
| Files: | 1,138 |
| Messages: | 111,071 |
Colin Percival <cperciva_at_freebsd.org> wrote:
With pkgbase being the intended way for users to manage 15.0 systems,
the current default /etc/pkg/FreeBSD.conf gives rise to confusion: It
defines a "FreeBSD" pkg repository which is in fact specifically bits
maintained *outside* of FreeBSD (and packaged via the ports tree).
Not that I consider an appropriate answer obvious, but
the file names as well as the content in the file? :
/etc/pkg/FreeBSD-ports.conf ?
The adjusted file naming would tend to suggest a separate file
for pkgbase content.
Naming left as it is might suggest all in one file, pkgbase
included.
On 8/19/25 17:17, Mark Millard wrote:Will a pkgbase repo be present and enabled by default?
Colin Percival <cperciva_at_freebsd.org> wrote:
With pkgbase being the intended way for users to manage 15.0 systems,Not that I consider an appropriate answer obvious, but
the current default /etc/pkg/FreeBSD.conf gives rise to confusion: It
defines a "FreeBSD" pkg repository which is in fact specifically bits
maintained *outside* of FreeBSD (and packaged via the ports tree).
the file names as well as the content in the file? :
/etc/pkg/FreeBSD-ports.conf ?
I wasn't planning on changing the file name, no.
The adjusted file naming would tend to suggest a separate file
for pkgbase content.
Naming left as it is might suggest all in one file, pkgbase
included.
Right, I don't see any reason for having separate files. If I thought people might want to delete one of them (e.g. rm /etc/pkg/FreeBSD-base.conf in order to disable pkgbase) then I would separate them; but the recommended way to disable a repository is with an {enabled: no} in /usr/local/etc/pkg/ so I don't see any need to separate these.
(But it's not a silly question -- there was some discussion in phabricator just recently about how we should distribute the base system pkg.conf file. That's next on my list after the FreeBSD -> FreeBSD-ports renaming...)Overall I end up more with questions than anything.
On Aug 19, 2025, at 17:25, Colin Percival <cperciva@freebsd.org> wrote:
Right, I don't see any reason for having separate files. If I thought people
might want to delete one of them (e.g. rm /etc/pkg/FreeBSD-base.conf in order
to disable pkgbase) then I would separate them; but the recommended way to >> disable a repository is with an {enabled: no} in /usr/local/etc/pkg/ so I
don't see any need to separate these.
Will a pkgbase repo be present and enabled by default?
present but disabled? Not present at all in
/etc/pkg/FreeBSD.conf ?
(I'm not trying to specify spelling for such here. But your
note might be better with this intended spelling also
being explicit so how it all fits together is more
clear.)
If /etc/pkg/FreeBSD.conf is intended not to be edited at all
by default, that might have implications for some default
content there or inside /usr/local/etc/pkg/repos/ someplace
if pkgbase is not enabled by default.
(My understanding is that pkgbase is off by default.)
On Aug 19, 2025, at 8:25 PM, Colin Percival <cperciva@freebsd.org> wrote:Why is then this file named rCLFreeBSD.confrCY ?
On 8/19/25 17:17, Mark Millard wrote:
Colin Percival <cperciva_at_freebsd.org> wrote:
With pkgbase being the intended way for users to manage 15.0 systems,Not that I consider an appropriate answer obvious, but
the current default /etc/pkg/FreeBSD.conf gives rise to confusion: It
defines a "FreeBSD" pkg repository which is in fact specifically bits
maintained *outside* of FreeBSD (and packaged via the ports tree).
the file names as well as the content in the file? :
/etc/pkg/FreeBSD-ports.conf ?
I wasn't planning on changing the file name, no.
To reduce long-term confusion, I'm intending to rename the "FreeBSD" repository to "FreeBSD-ports", and similarly rename "FreeBSD-kmods" to "FreeBSD-ports-kmods".Having "ports" in the repository name does not make sense to me at
It defines a "FreeBSD" pkg repository which is in fact specifically bits maintained *outside* of FreeBSD (and packaged via the ports tree).Can't agree with this either. FreeBSD Ports are maintained *inside*
On 8/19/25 17:44, Mark Millard wrote:
On Aug 19, 2025, at 17:25, Colin Percival <cperciva@freebsd.org> wrote:
Right, I don't see any reason for having separate files. If I thought people
might want to delete one of them (e.g. rm /etc/pkg/FreeBSD-base.conf in order
to disable pkgbase) then I would separate them; but the recommended way to >> disable a repository is with an {enabled: no} in /usr/local/etc/pkg/ so I >> don't see any need to separate these.
Will a pkgbase repo be present and enabled by default?
present but disabled? Not present at all in
/etc/pkg/FreeBSD.conf ?
(I'm not trying to specify spelling for such here. But your
note might be better with this intended spelling also
being explicit so how it all fits together is more
clear.)
If /etc/pkg/FreeBSD.conf is intended not to be edited at all
by default, that might have implications for some default
content there or inside /usr/local/etc/pkg/repos/ someplace
if pkgbase is not enabled by default.
(My understanding is that pkgbase is off by default.)
pkgbase is off by default in 14 but will be on by default in 15. People will need it to update their systems for security updates, for example, since freebsd-update is going away (at least in its present form -- it might turn into a wrapper around pkg).
Users who want to update the base system from another source (no pun intended)--
will need to configure their systems appropriately.
--
Colin Percival
FreeBSD Release Engineering Lead & EC2 platform maintainer
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
ItrCOs unclear (to me) whether thatrCOs the *correct* way, or the *recommended* way (pkg(8) calls it rCLa common idiomrCY), 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
Also, it seems that whether having rCLrepository-name: { enabled: false}rCY 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
On Aug 20, 2025, at 6:15 AM, Gleb Popov <arrowd@freebsd.org> wrote:This is true for so many files under /etc, and we have a solution with etcupdate (indeed, not 100% automatically, but widely accepted).
On Wed, Aug 20, 2025 at 12:48rC>PM Matteo Riondato <matteo@freebsd.org> wrote:
ItrCOs unclear (to me) whether thatrCOs the *correct* way, or the *recommended* way (pkg(8) calls it rCLa common idiomrCY), 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.
So encouraging users to not touch system configs but rather writeIt seems to me that we donrCOt have this encouragement with any other files in /etc.
add-ons to these configs make upgrades less painful.
This is also a very common problem which has an established solutionNo, REPOS_DIR is about _directories_, not files.
by prefixing config files with numbers, like
10-disable-freebsd-repos.conf
From: "Colin Percival" <cperciva@freebsd.org>
To: freebsd-current@freebsd.org, "freebsd-ports@FreeBSD.org" <freebsd-ports@freebsd.org>
Cc: "FreeBSD Release Engineering Team" <re@FreeBSD.org>
Sent: Wednesday, 20 August, 2025 00:49:23
Subject: RFC: Renaming "FreeBSD" repo in /etc/pkg/FreeBSD.conf to "FreeBSD-ports"
Hi everyone,
With pkgbase being the intended way for users to manage 15.0 systems,
the current default /etc/pkg/FreeBSD.conf gives rise to confusion: It
defines a "FreeBSD" pkg repository which is in fact specifically bits maintained *outside* of FreeBSD (and packaged via the ports tree).
To reduce long-term confusion, I'm intending to rename the "FreeBSD" repository to "FreeBSD-ports", and similarly rename "FreeBSD-kmods" to "FreeBSD-ports-kmods". The repositories will still work, and will still access the same URLs, but the change will be visible; probably the most common scenario where this would cause problems for users is if they have "FreeBSD: {enabled: no }" in /usr/local/etc/pkg/repos/FreeBSD.conf, since that would need to be adjusted to chase this change.
For obvious reasons, this change would not be MFCed.
++
You've got a week to convince me that this is a bad idea, otherwise I'll
make the change on the 27th; I want to get this out of the way before we
get too close to branching stable/15.
On Aug 19, 2025, at 17:51, Colin Percival <cperciva@freebsd.org> wrote:/usr/local/etc/pkg/repos/*.conf override /etc/pkg/FreeBSD.conf
On 8/19/25 17:44, Mark Millard wrote:
On Aug 19, 2025, at 17:25, Colin Percival <cperciva@freebsd.org> wrote: >>>> Right, I don't see any reason for having separate files. If I thought people
might want to delete one of them (e.g. rm /etc/pkg/FreeBSD-base.conf in orderWill a pkgbase repo be present and enabled by default?
to disable pkgbase) then I would separate them; but the recommended way to >>>> disable a repository is with an {enabled: no} in /usr/local/etc/pkg/ so I >>>> don't see any need to separate these.
present but disabled? Not present at all in
/etc/pkg/FreeBSD.conf ?
(I'm not trying to specify spelling for such here. But your
note might be better with this intended spelling also
being explicit so how it all fits together is more
clear.)
If /etc/pkg/FreeBSD.conf is intended not to be edited at all
by default, that might have implications for some default
content there or inside /usr/local/etc/pkg/repos/ someplace
if pkgbase is not enabled by default.
(My understanding is that pkgbase is off by default.)
pkgbase is off by default in 14 but will be on by default in 15.
With 15 or main [then: 16] as the context . . .
Will buildworld buildkernel installkernel installworld (not
referencing various steps) for folks using source code based
updates need to undo an addition of pkgbase from the
installworld activity? Never? Just once? Each time?
Or is "on by default" more selective somehow for such
contexts?
Note: In my context I'll have pkgbase in use for the
booted world and available for use as the booted kernel,
although I'll have personal-build alternate kernels too.
My from-source installed world will be in, for example, a
chroot directory tree(s) and in a poudriere jail world(s).
I keep /usr/src/ for pkgbase to manage for itself and have
a separate /usr/main-src/ (as an example).
So I'll be dealing with both types of contexts no matter
what.
People will
need it to update their systems for security updates, for example, since
freebsd-update is going away (at least in its present form -- it might turn >> into a wrapper around pkg).
Users who want to update the base system from another source (no pun intended)
will need to configure their systems appropriately.
... I would like to have a separate file for each repository, similar to the contents of /etc/newsyslog.conf.d/ or /etc/syslog.d/.
If there is one file for each repository, it can be managed using simple tools such as cp / rm / sed to enable, disable or modify repositories - good for scripted setups and automation. However, if there are multiple repositories in one file, this task becomes much more complicated.
On Aug 19, 2025, at 3:49rC>PM, Colin Percival <cperciva@freebsd.org> wrote:
Hi everyone,
With pkgbase being the intended way for users to manage 15.0 systems,
the current default /etc/pkg/FreeBSD.conf gives rise to confusion: It
defines a "FreeBSD" pkg repository which is in fact specifically bits maintained *outside* of FreeBSD (and packaged via the ports tree).
To reduce long-term confusion, I'm intending to rename the "FreeBSD" repository to "FreeBSD-ports", and similarly rename "FreeBSD-kmods" to "FreeBSD-ports-kmods". The repositories will still work, and will still access the same URLs, but the change will be visible; probably the most common scenario where this would cause problems for users is if they have "FreeBSD: {enabled: no }" in /usr/local/etc/pkg/repos/FreeBSD.conf, since that would need to be adjusted to chase this change.
For obvious reasons, this change would not be MFCed.
You've got a week to convince me that this is a bad idea, otherwise I'll
make the change on the 27th; I want to get this out of the way before we
get too close to branching stable/15.
--
Colin Percival
FreeBSD Release Engineering Lead & EC2 platform maintainer
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
On 20 Aug 2025, at 20:49, Bakul Shah <bakul@iitbombay.org> wrote:Having FreeBSD- prefix might indicate that the repository is maintained
Would prefer shorter names or aliases. This is all FreeBSD related so
why not just drop the FreeBSD- prefix?
But then this last name is wrong. There are kernel modules in the base systemI don't want to bikeshed this further, mainly because I feel that
as well, so that repository does not contain all of the project-provided kernel
modules.
All right, maybe "FreeBSD packages" looks like a superset of the
latter two, so we can call it "FreeBSD main packages", which aligns
nicely with "FreeBSD quarterly packages".
"main" vs "base" is not at all clear. Which one contains the package for /bin/ls? Is that in the "main" package set, or the "base" package set? Shouldn't the "main" package set contain the "main" parts of the system?
(Or at least, isn't it conceivable that some users will think that and get inevitably confused?)
I think using "ports" in the name is the best way to remove ambiguity.
I would be fine, btw, with using "src" in the name for the base pkg repository. I can understand why the logical project is called pkgbase instead of pkgsrc to avoid conflicting the other pkgsrc project, but these descriptions seem clear to me:
- "FreeBSD src"
- "FreeBSD ports"
- "FreeBSD ports kernel modules"
And they could be named "FreeBSD-src" and "FreeBSD-ports" without having any single repository named just "FreeBSD". This better aligns with how we name the base system in other places (src.git, github/freebsd/freebsd-src.git, etc.)