From nobody Wed Jan 22 01:43:00 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 4Yd6KW0N4sz5ltGM for ; Wed, 22 Jan 2025 01:43:11 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Yd6KV4rX2z3gm2 for ; Wed, 22 Jan 2025 01:43:10 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=citron; t=1737510182; x=1738176848; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:mail-followup-to:openpgp:blahblahblah: mime-version:content-type:content-transfer-encoding:author:from:subject: date:to:cc:resent-author:resent-date:resent-from:resent-sender:resent-to: resent-cc:resent-reply-to:resent-message-id:in-reply-to:references: mime-version:content-type:content-transfer-encoding:content-disposition: content-id:content-description:message-id:mail-followup-to:openpgp: blahblahblah; bh=mMiR5zEPwYhZ1V0hsEvlULCbQu41jRzmP1aaCRMKOIk=; b=MoWmpgxOS9PTaDFYwnqR/IVShOh4S6ixU9IBd3thNmf71yuh4VREgA5B6H3cB1fPWrpw/uAu rArRs+RTQYnsnS0GDHi9e3DaNuWDC+W3bIjcPI28sg56ueS0Iv49xIMCd8hf06g9YvgXQj5/Y1 WLX3D/I2V7ZKQbnU+/zXv95i1Mkn+SL+KyYemkErmWXS0OL3QSC9VRe0PYYgs5frHz2wwid57S It/XBopyeOaYr7m0SL+xBb0qxBfa3oYoNolWvhZa5Lx8gibmlBtql0QMFdB5zS4FHRbS++RGLD SvnKlxmB7Lp566FKN/nQQVMVhsQ8FUVw41zj8iPe2MFDeSGQ== DKIM-Signature: v=1; a=adaed25519-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=orange; t=1737510182; x=1738176848; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:mail-followup-to:openpgp:blahblahblah: mime-version:content-type:content-transfer-encoding:author:from:subject: date:to:cc:resent-author:resent-date:resent-from:resent-sender:resent-to: resent-cc:resent-reply-to:resent-message-id:in-reply-to:references: mime-version:content-type:content-transfer-encoding:content-disposition: content-id:content-description:message-id:mail-followup-to:openpgp: blahblahblah; bh=mMiR5zEPwYhZ1V0hsEvlULCbQu41jRzmP1aaCRMKOIk=; b=Dm7W4BafPIy6FTkUlVbATOZTnlhZkVwpIDTozUw46CxsByc+UDVVxjjBcVwGboV1uWG6Jbf2 o6D9lOzoAtWuDw== Date: Wed, 22 Jan 2025 02:43:00 +0100 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Warner Losh Cc: bob prohaska , Sulev-Madis Silber , freebsd-current@freebsd.org Subject: Re: /usr/src and /usr/ports not git directories ? Message-ID: <20250122014300.izn3kEWi@steffen%sdaoden.eu> In-Reply-To: References: Mail-Followup-To: Warner Losh , bob prohaska , Sulev-Madis Silber , freebsd-current@freebsd.org User-Agent: s-nail v14.9.25-636-gc7c14cee09-dirty OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. 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 X-Rspamd-Queue-Id: 4Yd6KV4rX2z3gm2 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:15987, ipnet:217.144.128.0/20, country:DE] Warner Losh wrote in : |On Tue, Jan 21, 2025 at 2:26=E2=80=AFPM bob prohaska = wrote: |> On Tue, Jan 21, 2025 at 10:35:18PM +0200, Sulev-Madis Silber wrote: |>> not shipping src in installer? what could possibly go wrong! |>> |>> i was just thinking of this the other day. that installers are |> self-contained packages that come with os and it's source... |>> |> There's no harm (and indeed, some good) in offering source code |> as a component of a new installation. What confused me was having |> that source code offered as a dead end. After a little poking around |> it's clear that including /usr/src/.git would have added close to |> to 2 GB to the size of the installer. Perhaps not unacceptable, |> but surely undesirable. Maybe that's reason enough for present |> practice of installing a dead /usr/src.. |> |> As a matter of naive curiosity, could one efficiently update /usr/src |> using something like sftp -ar ? It wouldn't preserve the revision detail |> git does, but seemingly it would download modified files while saving |> for re-use those that haven't changed. For users who don't make local |> mods it might be sufficient. |> |>> On January 21, 2025 10:09:43 PM GMT+02:00, Gleb Smirnoff < |> glebius@freebsd.org> wrote: |>> ... |>>>I think that /usr/src and /usr/ports as part of FreeBSD release |>>>distribution should just go away. But we should provide a one liner |>>>command to get them in a proper way (shallow git checkout). |>>> |> |> Do you mean have the "install src" checkbox invoke git clone? |> That seems like a better idea, at least to me. | |I think we should replace the populate /usr/src from a tarball with.... |populate it |with a tarball that represents a 1-deep checkout tree at the rev we built |the release |from. This lets users have the source, has minimal overhead and also lets |users update |or turn the shallow checkout into a deep one, etc. A shallow checkout is |quite a bit |less than a full tree, though still more than just the raw files. I've not |done poking to |see size comparisons. What i do is having a "null" branch, which contains only one file "NULL" which contains only the name of the master/xy branch. Ie i can do (equivalent of) "git checkout $(cat NULL)" to get the files populated, but can checkout that "null" branch to get rid of myriads of files, and the majority of space consumption. (Before someone complains again: i know about "bare" repositories, but this is not what i want to have here.) #?0|kent:tmp$ cd /x/os/linux.git #?0|kent:linux.git$ du -sh . 2.5G . #?0|kent:linux.git$ find . -type f | wc -l 52 #?0|kent:linux.git$ ll total 4K -rw-r----- 1 steffen code 7 Mar 30 2020 NULL drwxr-s--T 1 steffen code 16 Mar 30 2020 ./ drwsrws--T 1 root code 746 Dec 28 19:10 ../ drwxr-s--- 1 steffen code 178 Dec 28 19:13 .git/ #?0|kent:linux.git$ cat NULL master #?0|kent:linux.git$ cd /usr/src/linux-6.1/ #?0|kent:linux-6.1$ du -sh . 1.4G . #?0|kent:linux-6.1$ find . -type f | wc -l 78710 (Often i then however do "alias.ar archive --format=3Dtar" aka "git ar --prefix=3Dxy/ SOMECOMMIT| (cd TMPFS && tar -xf -)" instead as most projects i track i only track out of interest, and if i really need the files, then only temporary. (Problem here is that glibc build needs kernel checkout, and initially, without overcommitting tmpfs /tmp with size=3D170% -- NVME swap! -- space would have been insufficient for linux kernel compilation, too.)) Anyway, with such a thing all the many files are only a "git checkout" away, while initially there is only the git object pack. (And that can be --aggressive'ly packed to some large extend; i have not done that for OSs for a year, but the exim MTA i newly cloned from github a few weeks ago, for example, shrunk locally from 80 megabytes to only twenty: the git objects, that is.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | |In Fall and Winter, feel "The Dropbear Bard"s pint(er). | |The banded bear |without a care, |Banged on himself for e'er and e'er | |Farewell, dear collar bear