From nobody Tue Sep 23 22:32:03 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cWZV85wxnz682xN for ; Tue, 23 Sep 2025 22:32:16 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo75.interia.pl (smtpo75.interia.pl [217.74.67.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cWZV82XrFz3tLJ; Tue, 23 Sep 2025 22:32:16 +0000 (UTC) (envelope-from vermaden@interia.pl) Authentication-Results: mx1.freebsd.org; none Date: Wed, 24 Sep 2025 00:32:03 +0200 From: vermaden Subject: Re: For base packages, origin is always "base". To: Maxim Sobolev , Mark Millard , FreeBSD Developers Cc: FreeBSD Current , Baptiste Daroussin X-Mailer: interia.pl/pf09 In-Reply-To: References: <0EAFDC33-DC46-4A41-995B-1CE20395EF57.ref@yahoo.com> <0EAFDC33-DC46-4A41-995B-1CE20395EF57@yahoo.com> X-Originating-IP: 45.148.42.23 Message-Id: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1758666727; bh=sW+GLO7Ojufm+nYjgH4f7ReZNW7UanmydTRzWZAUZn4=; h=Date:From:Subject:To:Message-Id:MIME-Version:Content-Type; b=qxlyiqWL0M01yw8Sb0eMsnC1ST0mSEn2xwVXcd/zvGbcFFDYE3r0kebuQTaiIFp19 4ZwzYYoOVD7DTCIqPW4RZ/QY9bdqmiW9Kz2Fg3z/B/nWSzJqC3zP5lufqZqsBwdXNC /HG7ZVRTA0bKKVeMwf0YSbft38ivoxSQi/V0uvu0= X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cWZV82XrFz3tLJ 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" <de= velopers@freebsd.org>;=20 DW: "FreeBSD Current" <freebsd-current@freebsd.org>; "Baptiste Daroussin= " <bapt@freebsd.org>;=20 >=20 > > 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. >=20 > 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). >=20 > 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". >=20 > 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. >=20 > 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. >=20 > Any comments, ideas or suggestions are welcome. Thanks! >=20 > -Maxim >=20 > On Mon, Sep 22, 2025 at 6:24=E2=80=AFPM Mark Millard=20 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=3Dfb16dfecae4a6efac9f3a78e0b759fb7a= 3c53de4 >> >> 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=3D2ed924f5ecb1efe13229a0a77d5= e7a2c0cfaac09 >> >> 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! >> >> >> >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >> >> >=20 >=20 >=20