On Sun, Oct 17, 2021 at 11:01 AM Nathan Hartman <hartman.nat...@gmail.com> wrote: > > On Sat, Oct 16, 2021 at 9:25 AM Mark Phippard <markp...@gmail.com> wrote: > > > > In terms of the policy, I think it should be that our latest LTS > > release must be available. If they have other packages available that > > is fine but the latest LTS must be one of them. In terms of the types > > of exceptions I could envision, perhaps we will discover it is really > > difficult to package the latest LTS for certain older distros and so > > they need to provide an older version. I would be OK with an exception > > like this but I would prefer to have the packagers raise it to us. > > > > Mark > > > I'm not opposed to this, but it might be a little tricky for OS > distros that freeze package versions. Debian for example. I haven't > checked what the current stable (bullseye) has, but I'm still on the > oldstable (buster) which supplies 1.10.x. I'm running a recent trunk > build though, heh heh :-)
I can vouch for this in the Red Hat world. I used to publish ports of Subversion over at repoforge, but the various dependency updates got a bit out of hand for me to continue after Repoforge ended. And EPEL refuses to replace any RHEL published tools. Red Hat sometimes publishes updates as part of their "SCL" or software collections library, but those can be really finicky to work with. > I'm not proposing an exception (and I'm not a packager); rather I'm > suggesting to consider a package compliant as long as it was a > supported LTS release at the time of the packager's version freeze > and security issues continue to be patched. > > Thoughts? > > Nathan
