Re: rt-tests release tarball location

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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






[Index of Archives]     [RT Stable]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux