Re: The GSS-API split
On Tue, Nov 12, 2024 at 09:33:14AM -0300, Andreas Hasenack wrote:
> On Mon, Nov 11, 2024 at 6:57 PM Colin Watson <cjwatson@debian.org> wrote:
> > https://lists.debian.org/debian-devel/2024/04/msg00044.html has a
> > timeline, in the "GSS-API key exchange" section. The only change is
> > that I'm calling the packages openssh-*-gssapi rather than
> > openssh-*-gsskex, and pushing GSS-API authentication out to the other
> > side of the split along with key exchange.
>
> So the change you have in testing/trixie now is the full extent of
> what you plan to do there, just have the *-gssapi packages there,
> empty but for deps, which in trixie+1 will have actual content and be
> built from the new src package?
Yes.
> > It is necessary to wait for a Debian stable release with
> > openssh-*-gssapi before proceeding, to give people an opportunity for a
> > graceful upgrade.
>
> Do you plan on having the new src package in trixie experimental perhaps?
"trixie experimental" isn't really a thing, but if you mean "in
experimental before trixie releases" ... maybe? I don't really want to
spend more time than necessary merging changes back and forward between
source packages though.
> > Since Ubuntu has not kept up well with openssh merges (still on 9.7p1!),
> > you don't have the openssh-*-gssapi binary packages yet. I _strongly_
> > recommend that you get those merged along with the many other fixes from
> > upstream that you're missing, get them into 26.04 LTS with a suitable
> > release note telling people to install the openssh-*-gssapi packages if
> > they need GSS-API authentication or key exchange, and then you'll be
> > able to follow the source package split in 26.10 or later.
>
> Yeah, the merge is behind.
>
> I was hoping to start this change now, for 25.04, or 25.10 at the
> latest, so that it would have stabilized for 26.04.
Well, you'd need to get the empty *-gssapi binary packages into 26.04 in
order to be able to do the second stage of the split for 28.04.
Otherwise anyone actually using GSS-API in Ubuntu won't have a
reasonable upgrade path.
Is there really a good reason that the unique-ccache patch needs to
block on proceeding further with the package split? Yes, in theory it
would reduce the risk a bit, but it's already mostly behind a new
off-by-default configuration option. I think that rushing the package
split in order to apply unique-ccache is bad tactics, and if you want to
apply unique-ccache then you should just do it in advance of the split.
> There is no indication of when trixie will be released yet, right,
> just "sometime in 2025"?
Not yet, no. But if you look at
https://en.wikipedia.org/wiki/Debian_version_history, Debian's had a
fairly reliable two-year cadence (plus or minus a few months) since
2005, so mid-2025 seems like a pretty good bet.
Given that, I expect that Ubuntu 26.04 will be the blocker for
proceeding with the second stage of the split, not trixie.
--
Colin Watson (he/him) [cjwatson@debian.org]
Reply to: