Date: Thu, 23 Jan 2025 04:38:16 +0100 From: Florian Walpen <dev@submerge.ch> To: freebsd-current@freebsd.org, Gleb Smirnoff <glebius@freebsd.org> Cc: bob prohaska <fbsd@www.zefox.net>, Warner Losh <imp@bsdimp.com> Subject: Re: /usr/src and /usr/ports not git directories ? Message-ID: <8355934.G18vQ0XA4d@z240> In-Reply-To: <Z5GgSiETH9rwsMT6@cell.glebi.us> References: <Z4vk3009iSwuzG4K@www.zefox.net> <2019698.n1Ql7ez4OO@x230> <Z5GgSiETH9rwsMT6@cell.glebi.us>
next in thread | previous in thread | raw e-mail | index | archive | help
Gleb, On Thursday, January 23, 2025 2:50:02 AM CET Gleb Smirnoff wrote: > I can't understand why would you need to rebuild anything if you are > running RELEASE and packages? If that ever happened, this is definitely > fault of either someone's merge to stable, or maintainers of drm-kmod. > But this can't be taken as a good reason to have those stub sources. nobody's fault, this is a conceptual problem. There's only one package build per major release, say 13 or 14. That works well for most packages because the minor releases are ABI compatible. But not for kernel modules, the minor releases don't maintain KBI compatibility. This has always been an issue, it's just that the introduction of the drm-*-kmod and their fast pace of development exposed it to a vast number of people. As an example, when 14.1-RELEASE came out, the package builder machines would still be running 14.0-RELEASE, producing kernel modules that were incompatible with 14.1 - up until 14.0 was EOL three months later, and the builder machines were updated. Actually even the recommended drm version changed for 14.1, thus you couldn't install the recommended version, it simply didn't build on 14.0. The remedy is clearly to build kernel module packages for every minor release, and there has been an attempt to do this recently, through a separate pkg repo I think. Don't know how "official" it is. Before that the solution was always to build from ports, there's plenty of threads about this topic on the forums. > > F> It's not exactly clear to me what problem you want to solve? As a > developer or F> someone doing src builds, updates are coming through git > and packaging is not F> that relevant. Sure a one-liner would be nice. IIRC > DragonflyBSD had those in a F> Makefile, that was quite convenient. Does > installing the src tree as a git repo F> have any tangible benefits over > that? > > The problem in my view is that we ship something that is useless in vast > majority of the cases. In majority of the cases work starts with: > > rm -rf src && git checkout ... > > For those, who not yet learned that this is the normal beginning of work, > the mere existense of the directory is misleading. Installing the src tree as a non-git snapshot is useless for developers and people that update through src builds, I agree with that. 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 installing the git executable and updating the src tree. As stated, we could simplify the post-install repo cloning through a Makefile. But I don't agree about the static src tree being useless for people that do binary updates, there are good reasons to build from ports. Also I would imagine it simplifies the installation of poudriere jails. 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 issues. Better simplify repo cloning through a Makefile, post-install, no dependency on git in the installer. Or am I missing some critical use case? Regards, Flo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8355934.G18vQ0XA4d>