Date: Thu, 26 Mar 2026 15:51:43 -0700 From: Mark Millard <marklmi@yahoo.com> To: polyduekes@proton.me Cc: freebsd-pkgbase@freebsd.org, Lexi Winter <ivy@freebsd.org> Subject: Re: installing world from src on a pkgbase system Message-ID: <3ff6c824-d9a1-426b-aa04-d19d1ee1c958@yahoo.com> In-Reply-To: <rEAmq8agYj3xi9v_2o4OifyAJfDB9NHeaX30b78pgwIeORvz7_R4qpmR_vEKEemmhZfe096lVlIr2BaPAK1BFrD3EMz5zXNOC1BFAD0x-wE=@proton.me> References: <UGVbTfxFnLh7zkFaMJrCf_Fll6DjeBxw5VK_kc_jdLlOlJPe6QtfNOQm23v-DOSO-DP1YiEcP8APpn9To22Lc64V-oX24Mor7jSE_ZtYmj8=@proton.me> <acRQcjyIZ_Krfyw4@amaryllis.le-fay.org> <m-cS1PTzow3fGVjDOpYyn6W_o4S1wWeW_rAts1LiWRgqkb4CXug6y8weHusL07G9vt2l5WGX76OF2C-JckHufUvwSqJ4511_3wNZ81QeOz4=@proton.me> <acRZ6iRoJPgZUFmt@amaryllis.le-fay.org> <pcRls0mXL2DAbxhH0bMX_DPGdlHbwm8fNM9fEAJXVBZgoqxfP1mCHAA9wsCDbvl9AeV4_BNhd3UZqCpBtLgMI59ZirMmwsLNsLeVmoVY__0=@proton.me> <be4dc8f9-84b7-456f-8f64-d09488be3dc6@yahoo.com> <rEAmq8agYj3xi9v_2o4OifyAJfDB9NHeaX30b78pgwIeORvz7_R4qpmR_vEKEemmhZfe096lVlIr2BaPAK1BFrD3EMz5zXNOC1BFAD0x-wE=@proton.me>
index | next in thread | previous in thread | raw e-mail
On 3/26/26 12:38, polyduekes@proton.me wrote: > yes i am aware of meta mode and i do use it but i usually pull the latest snapshot of the kernel package available instead of updating kernel from src since i don't make my own changes to the kernel, so that means every time i update the src tree via 'git pull' and everytime updating the src tree brings a kernel change, the time spent to compile that is wasted time especially since my machine isn't really powerful FYI . . . git pull results need not always match the source code for the official pkgbase package distribution of interest unless you are being very careful. pkgbase publishes the source directory trees for its distributions independently of git: FreeBSD-src-*.pkg ( provides /usr/src/ without /usr/src/sys/ ) FreeBSD-src-sys-*.pkg ( provides /usr/src/sys/ ) The the 2 are not necessarily even from the exact same commit in git unless it is a base_release_* pkgbase instead of a base_latest or base_weekly one (and no new release update has been started): the kernel and world source need not be grabbed or built at the same time for base_latest or for base_weekly and more commits might have happened between the world and kernel builds. (There can be some additional risk if the kernel's source code was older than the world's source code as the world built might be dependent on a later change to the kernel source code. Typically this probably prevents such a world's build from finishing.) (See below for details the above wording does not cover.) As stands . . . For base_release_* for some FreeBSD:15:ARCH : pkgbase is based on a releng/15.*/ and the source should match as long as that release has not started a new update sequence for the next update to a new -p? release. A base_release_* distribution does not update based on just new commits to its releng/15.*/ but only at/for the official release-update distribution process that happens later. For base_release_* for some FreeBSD:14:ARCH : pkgbase is based on releng/14.*/ snapshots but may update during the middle of changes for the next release update to a new -p? release, tracking its releng/14.*/ that may be in development instead of finished. A pkgbase distribution time is possibly later then the build time. For base_latest or base_weekly for some FreeBSD:1[45]:ARCH : pkgbase is based on stable/* snapshots and need not match git pull at a specific commit. pkgbase base_latest updates 2 times per day if new commits are present and the build works. A pkgbase distribution time is possibly later then the build time. For base_latest or base_weekly for some FreeBSD:16:ARCH : pkgbase is based on main/ and need not match a git pull at a specific commit. pkgbase base_latest updates 2 times per day if new commits are present and the build works. A pkgbase distribution time is possibly later then the build time. Such is my understanding. I've no clue which if the above your activity might involve. > > -------- Original Message -------- > On Thursday, 03/26/26 at 22:22 Mark Millard <marklmi@yahoo.com> wrote: > On 3/26/26 04:30, polyduekes@proton.me wrote: >> On Thursday, March 26th, 2026 at 3:26 AM, Lexi Winter <ivy@freebsd.org> wrote: >> >>> polyduekes@proton.me wrote in <m-cS1PTzow3fGVjDOpYyn6W_o4S1wWeW_rAts1LiWRgqkb4CXug6y8weHusL07G9vt2l5WGX76OF2C-JckHufUvwSqJ4511_3wNZ81QeOz4=@proton.me>: >>>> is needing to do both buildworld and buildkernel to create a pkg repo >>>> the intended behaviour or is that planned to change >>> >>> right now i don't believe there are any plans to change that. i suppose >>> it might change in the future. usually people want to build both the >>> world and the kernel, so this isn't an oft-requested feature. >>> >>> could you elaborate on why you want to build world but not kernel? >>> this would help inform development efforts in that area. >>> >> i usually make my own changes to base code to test some things and learn a few others,and most of the time the changes i make touch only world and dont touch kernel at all,so i like to avoid unnecessary compilation of the binaries and things i didn't change and doing only make buildworld and not make buildkernel buildworld is part of that reason > > Are you aware of META_MODE for buildworld and buildkernel (with its use > of filemon.ko)? Its purpose is to keep track of things and so generally > rebuild what is necessary but avoid rebuilding what is not. For example, > back to back rebuilds have the second one not taking very long based on > the lack of changes. > >>>> additionally may i ask why it's recommended to do 'make >>>> upodate-packages' over 'make packages' >>> >>> 'update-packages' will copy unchanged packages from the previous build >>> to the current build, which means if only a small number of packages >>> have changed, the system won't try to update every package. >>> >> >> > > > -- > === > Mark Millard > marklmi at yahoo.com > > > -- === Mark Millard marklmi at yahoo.comhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ff6c824-d9a1-426b-aa04-d19d1ee1c958>