From nobody Thu Jan 23 07:10:47 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 4YdsYS61Twz5ll45 for ; Thu, 23 Jan 2025 07:11:08 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-out.digsys.bg (smtp-out.digsys.bg [192.92.129.33]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp-out.digsys.bg", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YdsYS2vmkz3V9K; Thu, 23 Jan 2025 07:11:08 +0000 (UTC) (envelope-from daniel@digsys.bg) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple ([193.68.138.20]) by smtp-out.digsys.bg (8.16.1/8.16.1) with ESMTPS id 50N7Avar010705 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 23 Jan 2025 09:10:58 +0200 (EET) (envelope-from daniel@digsys.bg) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digsys.bg; s=registerbg; t=1737616258; bh=ig5GemGFDI0ccxrm7MB0ke/s5UNnSIiguDusOavcSIg=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=Q4BBS12h268Ko08FEPHDd1k+gWPOWHepSH+2/nPJHrnRofPaFHw1JgbIaFGfQlK/W QVLhEgHLn5ywaNFtj1XZYhSTdx3bfJ0lfDW4ELwgYZGQBAF9HwXcXXmZgt+RLXtv6x KShkoYQEyz7GGsoSIubE1K6/6q4QxP6DN5bSRgFFm0X5dA4JrjAtC+zNieOeioQ/Qe Vans/ZYs6n8czclD6KQ1gy09Tx9dKZwNB/qfr1u27jnAsKv1lFXJ2/aO+9J5IHNAo1 EEEr/yPNnfB0XPrJsoOQf+QesqE/kBOX+G39UIsqi9dFCqqGEchNg55/Z1sDv0DMn3 XV1hvAYJ/PIDA== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Daniel Kalchev 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 (1.0) Subject: Re: /usr/src and /usr/ports not git directories ? Date: Thu, 23 Jan 2025 09:10:47 +0200 Message-Id: References: <8355934.G18vQ0XA4d@z240> Cc: freebsd-current@freebsd.org, Gleb Smirnoff , bob prohaska , Warner Losh In-Reply-To: <8355934.G18vQ0XA4d@z240> To: Florian Walpen X-Mailer: iPhone Mail (22C161) X-Rspamd-Queue-Id: 4YdsYS2vmkz3V9K X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:3245, ipnet:192.92.129.0/24, country:BG] > =D0=9D=D0=B0 23.01.2025=E2=80=AF=D0=B3., =D0=B2 5:38, Florian Walpen =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=