On Wed, 2025-01-08 at 13:21 -0500, John Kacur wrote: > > On Tue, 7 Jan 2025, Sebastian Andrzej Siewior wrote: > > > +John, +Clark > > On 2025-01-07 10:41:37 [+0100], Kurt Kanzenbach wrote: > > > On Sat Dec 28 2024, Thomas Petazzoni wrote: > > > > Hello, > > > > > > > > I am one of the co-maintainers of Buildroot, an embedded Linux build > > > > system. Among many other packages, we obviously have rt-tests as one of > > > > our packages. When rt-tests is built, we download it from kernel.org. > > > > Unfortunately, the rt-tests tarballs are moved around: the latest > > > > release is available at https://www.kernel.org/pub/linux/utils/rt-tests/, > > > > but as soon as another newer release is available, the older release > > > > tarballs get moved to > > > > https://www.kernel.org/pub/linux/utils/rt-tests/older/. > > > > > > > > This breaks the build for build systems such as Buildroot, that expect > > > > a release tarball to stay at a given location, and not being moved > > > > around. > > > > > > > > Would it possible to keep the tarballs at the same location? Either by > > > > not having the older/ folder entirely, or by populating it immediately > > > > with the latest release, so that all releases are always available from > > > > the older/ folder? > > > > John, any favorites? > > > > We've been doing this for 15+ years. Normally I would expect the package > creators to come-up with a work around and not expect the people offering > the packages to accomdate your packaging software. Even when the status quo is both weird (unstable URLs are bad in general) and has caused issues for multiple packagers, and there's a simple fix? > > How many kernels back to you need to keep? Could we come up with a > compromise where we keep the newest kernel, plus say the last 3 in the > rt-tests directory before they get moved to the older directory? Or just don't move anything, and keep everything in "older" including the latest release, with the latest release also being in the current spot (i.e. Thomas's second suggestion). Or turn older/ into a symlink to the current directory, for compatibility only, maybe with a "latest" symlink to the current release. -Crystal