Date: Thu, 23 Jan 2025 09:10:47 +0200 From: Daniel Kalchev <daniel@digsys.bg> To: Florian Walpen <dev@submerge.ch> Cc: freebsd-current@freebsd.org, Gleb Smirnoff <glebius@freebsd.org>, bob prohaska <fbsd@www.zefox.net>, Warner Losh <imp@bsdimp.com> Subject: Re: /usr/src and /usr/ports not git directories ? Message-ID: <E92B3DB4-E21B-49BB-800E-807DBF0A2C84@digsys.bg> In-Reply-To: <8355934.G18vQ0XA4d@z240> References: <8355934.G18vQ0XA4d@z240>
next in thread | previous in thread | raw e-mail | index | archive | help
> =D0=9D=D0=B0 23.01.2025=E2=80=AF=D0=B3., =D0=B2 5:38, Florian Walpen <dev@= submerge.ch> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0: >=20 > The remedy is clearly to build kernel module packages for every minor rele= ase, > and there has been an attempt to do this recently, through a separate pkg r= epo > I think. Either that, or do the kernel module compilation locally. For this you need t= he matching kernel source, which is there for binary updated systems (via fr= eebsd-update). You only need the matching ports three or to ship the ports s= ources as part of the package itself, which might get ugly if there are lots= of dependencies. But in any case, a source tree matching the kernel is requ= ired.=20 > My take is that > installing the src tree is optional, giving a hint in the installer should= be > enough. There will be secondary steps anyway in this scenario, like instal= ling > the git executable and updating the src tree. As stated, we could simplify= the > post-install repo cloning through a Makefile. I would say FreeBSD should always ship with its source code - this has been a= major feature. It can be life saver if you get offline as all the necessary= tools to rebuild are already there. We should not =E2=80=9Cover-git=E2=80=9D stuff, especially as the git tool i= s not part of the build! Whether the shipped tree should be git ready=E2=80=A6 I can=E2=80=99t make m= y mind yet. Maybe it will be useful. For example, when things get messed up w= ith binary updates, I usually pull a =E2=80=9Cfresh=E2=80=9D releng arc tree= , recompile and reinstall and I am in a good =E2=80=9Cbinary=E2=80=9D state t= o continue using the binary updates on that host. If the src tree already ha= s git attributes, it would be just a matter of selecting the branch. Less ti= me waiting and less load on servers. >=20 > What is more questionable in my POV is to provide a by then outdated ports= > tree. It needs network access anyway, and is an invitation to security iss= ues. > Better simplify repo cloning through a Makefile, post-install, no dependen= cy on > git in the installer. Or am I missing some critical use case? I agree the ports tree is not extremely useful as shipped, except=E2=80=A6 y= ou get an outdated system lying around that for some reason you can=E2=80=99= t update and you need to install specific software in it.. for example, git -= so that =E2=80=A6 you can update. Happened to me few times. Precompiled pac= kages are not available anymore for those=E2=80=A6 new ports tree won=E2=80=99= t work for multitude of reasons. There should be a snapshot of the ports tre= e for the release so you know anything you build from there will be compilab= le/compatible with that base. It may have other issues, but that=E2=80=99s d= ifferent topic. We used to have the very useful portsnap tool, which did just that. A very s= implified interface to updating the ports tree. Instead of junking it, it sh= ould have been updated to manage git base clones. Anyway, in today=E2=80=99s= git clone of the ports =E2=80=9Cmake update=E2=80=9D works as expected. Daniel=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E92B3DB4-E21B-49BB-800E-807DBF0A2C84>