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:05:44 UTC
On Mon, Jul 15, 2024 at 3:57 PM Colin Percival <cperciva@freebsd.org> wrote: > On 7/15/24 14:33, Tomoaki AOKI wrote: > > On Mon, 15 Jul 2024 11:58:16 -0700 > > Colin Percival <cperciva@freebsd.org> wrote: > >> Extending the minor-release support period might be possible, but that > >> would depend on portmgr and secteam and I can't speak for them. One > issue > >> which would certainly come up is kernel module packages -- our packages > >> are built for each stable branch on the oldest currently supported > release, > >> which means that e.g. new features in 14.1 can't be used until 14.0 is > EoL; > >> this is a problem particularly for graphics drivers. > > > > How do you think about flavorizing kmod ports in kmod.mk and provide > > pkgs for latest patch release (like 14.0-p8) of all supported > > point releases (like 14.0) [1]? > > Does it look possible and feasible? > > Rebuilding kernel modules for each patch level shouldn't be necessary. If > we break KBI in a security or errata update, something has gone > astonishingly > wrong. > > 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. Ideally, we'd keep the same KBI per major release, but that ideal has fallen short. Warner