On Tue, Nov 12, 2024 at 09:33:14AM -0300, Andreas Hasenack wrote: > On Mon, Nov 11, 2024 at 6:57 PM Colin Watson <[email protected]> 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) [[email protected]]
