Re: Supporting RT5 in backports requires binary packages only in backports
Hi Dominic,
> Since we missed the deadline to get RT5 into bullseye, we would like
> to support this in bullseye-backports instead. The package itself
> is straightforward, and we expect to migrate to bookworm with no
> issues after the release.
>
> There are also extension packages which build multiple binary names
> from a single source (eg rt4-extension-foo and rt5-extension-foo). Because
> we don't plan to ship RT4 in bookworm, we'd like to remove it from
> unstable soon after the release. However we will need to continue to
> ship RT4 extension backports, since the current RT4 extension packages are
> not coinstallable with the RT5 ones.
>
> In practice the packages are almost identical, with the extension
> files being installed to the relevant versioned directories to
> be picked up by the right version of RT. And on the source packaging
> side, adding/removing support for major versions of RT is usually just
> changing one or two variables in debian/rules (plus the debian/control
> entry of course), so I would judge that as being a minimal changes that
> fits the spirit of backporting.
>
> I can't see any explicit mention of backports adding binary packages
> that aren't in the testing release in
> https://backports.debian.org/Contribute/, so I'm going to assume it's not
> forbidden, but since it's a slightly unusual case I figured I should
> raise it here in good time.
Long mail, short answer :). In fact we only require the source package
to be in testing. We had several examples of packages adding
(deprecated, python2, ...) binary packages in the past. I am not the
biggest fan of doing such things (those binary packages aren't tested in
testing in advance), however I see the need and I think we should accept
the disadvantage(s). Therefore, go ahead with this plan and thanks a lot
for asking.
Alex - Backports ftpmaster
Reply to: