Re: For base packages, origin is always "base".
- In reply to: Maxim Sobolev : "Re: For base packages, origin is always "base"."
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 23 Sep 2025 22:32:03 UTC
There was time when GhostBSD 'Base System' were in their Ports tree.
They had just another 'os' category under which it happened.
#/ BUILD GhostBSD os BASE PORTS /#
builder # poudriere bulk -j 13-2-R-amd64-src -p ghostbsd \
os/buildkernel \
os/buildkernel-debug \
os/buildworld \
os/kernel \
os/kernel-debug \
os/kernel-debug-symbols \
os/kernel-symbols \
os/userland \
os/userland-base \
os/userland-base-bootstrap \
os/userland-bin \
os/userland-boot \
os/userland-conf \
os/userland-debug \
os/userland-devtools \
os/userland-docs \
os/userland-lib \
os/userland-lib32 \
os/userland-lib32-development \
os/userland-rescue \
os/userland-sbin \
os/userland-tests \
os/ports \
os/src
Some more details here:
- https://vermaden.wordpress.com/2023/12/09/personal-freebsd-pkgbase-update-server/
I always liked that idea.
Regards,
vermaden
Temat: Re: For base packages, origin is always "base".
Data: 2025-09-23 21:48
Nadawca: "Maxim Sobolev" <sobomax@freebsd.org>
Adresat: "Mark Millard" <marklmi@yahoo.com>; "FreeBSD Developers" <developers@freebsd.org>;
DW: "FreeBSD Current" <freebsd-current@freebsd.org>; "Baptiste Daroussin" <bapt@freebsd.org>;
>
> > 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
wrote:
>>
>> Sulev-Madis Silber
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 2023-02-13 21:14:34 +0000
>> committer John Baldwin 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
>>
>>
>
>
>