Re: Change to FreeBSD release scheduling etc.
- Reply: Colin Percival : "Re: Change to FreeBSD release scheduling etc."
- In reply to: Colin Percival : "Re: Change to FreeBSD release scheduling etc."
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 15 Jul 2024 22:59:49 UTC
On Mon, Jul 15, 2024 at 4:20 PM Colin Percival <cperciva@freebsd.org> wrote: > On 7/15/24 15:05, Warner Losh wrote: > > On Mon, Jul 15, 2024 at 3:57 PM Colin Percival <cperciva@freebsd.org > > <mailto:cperciva@freebsd.org>> wrote: > > Flavouring kernel module ports for each minor release -- possibly > building in > > in an oldest-supported-release jail but with the relevant > /usr/src/sys tree -- > > might work well? But that's a question for portmgr; I don't know > enough about > > how package building works to know how feasible this would be. > > > > People have talked about "stacking" repos to accomplish this. We'd build > per-minor > > release images for .ko's. I'm not sure what the sticking points are for > doing > > this, > > though. > > That would be good, but drm-14.1-61-kmod-6.1.69_2 (aka have multiple > versions > of ports and require users to kmod packages to pick the right now) would be > better than what we have now. > Indeed, but the upgrade path sucks for that. And all the infrastructure is in place to start doing the per-minor-release repos to augment the per major release ones. I'm unsure what the holdup is, though. I've cc'd baptiste who may know. It's the least bad solution, though. It solves the problem for release points, but not for people on stable between releases (except accidentally sometimes when things haven't yet diverged), nor for current (since it's nothing but breakage of KBIs :). For that problem, only a build-from-source-for-each-new-kernel-build can work. > > Ideally, we'd keep the same KBI per major release, but that ideal has > fallen > > short. > > Having a stable KBI only solves half of the problem. With DRM especially > it's > useful for people running the latest minor release to use kmods which make > use > of functionality which was added in the latest release before the previous > release is EoLed. > Functionality added where? I'm not following the point you're making here... But since KBI stability isn't going to happen (at least given our past track record and a lack of tools to enforce it), it may be just an academic exercise. Warner