Re: For base packages, origin is always "base".

I have not looked into pkgbase implementation, but would it be too
crazy to suggest that we should at least try to re-use some of the
ports infrastructure to create those packages? This lines up with the
idea that I had for many years that we, as a project, need to support
packages coming from the multiple separately maintained "port trees"
in order to resolve some of the long-standing issues with how ports
operate, both on technical level and organizationally. Those could be
either sub-project trees (pkgbase, gnome, kde etc), or even private
vendor trees. Then we can have a totally separate pkgbase_ports
repository that would re-use some of the existing bsd.port.mk
infrastructure to maintain those.

We have a success story here operating such a vendor tree at Sippy
Software, where all our internal components (~70 at the time of this
writing) are managed as private ports in a private ports sub-tree for
the past 15 years. Since we are only interested in a single system
image (i.e. no incremental updates), none of it has been integrated
into pkg tools, but I see no technical obstacles for this to be
generalized further to make it more broadly applicable (ENOTIME
mostly).

Technically this can be achieved by embedding "srcrepo" parameter into
a package along with the "origin", so this tuple would uniquely
identify origin of any package allowing intelligent handling of
updates and upgrades, as well as proper integration with tools like
portupgrade. So for packages coming out of the third-party ports this
would be simply "https://github.com/freebsd/freebsd-ports@main", and
for hypotetical 16.3 pkgbase -
"https://github.com/freebsd/pkgbase-ports@releng/16.3".

Once this is in place, we can look into making inter-tree dependencies
working when building, so that the set of packages we or someone else
builds can source ports from a different potentially
independently-maintained port trees. This would allow then an
"official third-party FreeBSD software package" to depend on the
"official FreeBSD pkgbase package" if necessary (e.g. specific
libs/bin to run), or use a port from a vendor-specific tree without
pulling it into our own tree. Some tooling and bsd.port.mk changes
would be necessary at this stage to do steps necessary to "compile"
(i.e. pull from git and arrange locally) all trees in the dependency
chain, but again I see no huge technical obstacles there either.

Just in case, I am the original author of the "origin" feature and
some of the "early" (back then cutting-edge) large scale bsd.port.mk
portmgr-stype reorganization efforts before portmgr even existed, so I
consider myself at least to a some degree qualified to bring those
ideas here now.

Any comments, ideas or suggestions are welcome. Thanks!

-Maxim

On Mon, Sep 22, 2025 at 6:24 PM Mark Millard <marklmi@yahoo.com> wrote:
>
> Sulev-Madis Silber <freebsd-current-freebsd-org111_at_ketas.si.pri.ee> wrote on
> Date: Mon, 22 Sep 2025 22:19:03 UTC :
>
> > the subject is what i found from
> >
> > release/packages/template.ucl
> >
> > when i tried to figure out why
> >
> > pkg info -qoa
> >
> > gave me series of "bases" on my current-with-pkgbase test
> >
> > i had to do
> >
> > pkg query %n
>
> There is also the likes of:
>
> # pkg query "%n-%v" | less
> pkg: Warning: Major OS version upgrade detected.  Running "pkg bootstrap -f" recommended
> FreeBSD-acct-16.snap20250915234127
> FreeBSD-acct-dbg-16.snap20250915234127
> FreeBSD-acpi-16.snap20250910190529
> FreeBSD-acpi-dbg-16.snap20250905060419
> . . .
>
> It also shows the version information (that has
> an encoded date/time in the name).
>
> I'll note that there is also remote query:
>
> # pkg rquery "%n-%v" | less
> pkg: Warning: Major OS version upgrade detected.  Running "pkg bootstrap -f" recommended
> FreeBSD-acct-16.snap20250915234127
> FreeBSD-acct-dbg-16.snap20250915234127
> FreeBSD-acpi-16.snap20250910190529
> FreeBSD-acpi-dbg-16.snap20250905060419
> . . .
>
> and its "-r" variation, such as:
>
> # pkg rquery -rFreeBSD-base "%n-%v" | less
> pkg: Warning: Major OS version upgrade detected.  Running "pkg bootstrap -f" recommended
> FreeBSD-acct-16.snap20250915234127
> FreeBSD-acct-dbg-16.snap20250915234127
> FreeBSD-acpi-16.snap20250910190529
> FreeBSD-acpi-dbg-16.snap20250905060419
> . . .
>
> (pkg query does not involve or support -rFreeBSD-base
> or the like.)
>
> > or
> >
> > pkg query %C/%n
>
> For visual reference:
>
> # pkg query "%C/%n" | less
> pkg: Warning: Major OS version upgrade detected.  Running "pkg bootstrap -f" recommended
> base/FreeBSD-acct
> base/FreeBSD-acct-dbg
> base/FreeBSD-acpi
> base/FreeBSD-acpi-dbg
> . . .
>
> # pkg rquery -rFreeBSD-base "%C/%n" | less
> pkg: Warning: Major OS version upgrade detected.  Running "pkg bootstrap -f" recommended
> base/FreeBSD-acct
> base/FreeBSD-acct-dbg
> base/FreeBSD-acpi
> base/FreeBSD-acpi-dbg
> . . .
>
> > in order to get "real package names". latter blows up if more than one category is added, of course
>
> As an example, base/FreeBSD-acct is not a 'real base package name'
> at all (note the extra word before "package"):
>
> # pkg info base/FreeBSD-acct
> pkg: Warning: Major OS version upgrade detected.  Running "pkg bootstrap -f" recommended
> pkg: No package(s) matching base/FreeBSD-acct
>
> By contrast:
>
> # pkg info FreeBSD-acct-16.snap20250915234127
> pkg: Warning: Major OS version upgrade detected.  Running "pkg bootstrap -f" recommended
> FreeBSD-acct-16.snap20250915234127
> Name           : FreeBSD-acct
> Version        : 16.snap20250915234127
> Installed on   : Tue Sep 16 20:57:58 2025 PDT
> Origin         : base
> Architecture   : FreeBSD:16:amd64
> Prefix         : /
> Categories     : base
> Licenses       : BSD2CLAUSE
> Maintainer     : re@FreeBSD.org
> WWW            : https://www.FreeBSD.org
> Comment        : System Accounting Utilities
> Shared Libs required:
>         libc++.so.1
>         libc.so.7
>         libcxxrt.so.1
>         libgcc_s.so.1
>         libm.so.5
>         libxo.so.0
> Annotations    :
>         FreeBSD_version: 1600000
>         repo_type      : binary
>         repository     : FreeBSD-base
>         set            : base
> Flat size      : 129KiB
> Description    :
> System Accounting Utilities
>
> > is there any reason the origin can't be like with "normal" (ports) packages? any technical things i don't see here? dependencies from ports can't be resolved anymore? i mean yes category and name is correct. but i mean why? :)
>
> The notation base/FreeBSD-acct is supposed
> to mean that (presuming default ports placement)
> /usr/ports/base/FreeBSD-acct/ is were to
> find the content for base/FreeBSD-acct .
> That is not where any of the files are for
> the acct base package.
>
> The files related to base packages are not in the
> ports tree at all, but in the src git repository
> (usually used via /usr/src/ references). They are
> not stored with the pkg program source: they are
> FreeBSD configuration files that pkg processes.
>
> Also, the ports git repository has a history
> that includes time period that had a category
> "base", the last before that was removed is
> visible via:
>
> https://cgit.freebsd.org/ports/tree/?id=fb16dfecae4a6efac9f3a78e0b759fb7a3c53de4
>
> It shows a "base" directory. Looking in it,
> there was:
>
> base/Makefile
> base/README
> base/binutils/
> base/gcc6/
>
> The commit that removed that base directory was:
>
> https://cgit.freebsd.org/ports/commit/base?id=2ed924f5ecb1efe13229a0a77d5e7a2c0cfaac09
>
> author John Baldwin <jhb@FreeBSD.org> 2023-02-13 21:14:34 +0000
> committer John Baldwin <jhb@FreeBSD.org> 2023-02-13 21:14:34 +0000
>
> commit 2ed924f5ecb1efe13229a0a77d5e7a2c0cfaac09 (patch)
> tree d26d1548ef28cbecf4630f49462c79367d59e7af /base
> parent f3b6cfcaa96240335e8c343a90bcbfa3ff7534c7 (diff)
>
> base/*: Remove the base ports to install an external toolchain in /usr.
>
> . . .
>
> Avoiding confusions with the ports tree base category
> and its history seems appropriate to me.
>
> > i even wanted to change it but there must be a reason for this and i thought i ask first. maybe get some insight to this too
> >
> > this is my first try with pkgbase!
>
>
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>