systemtap in -backports pocket?
Dan Streetman
ddstreet at ieee.org
Tue Mar 8 22:47:22 UTC 2022
On Tue, Mar 8, 2022 at 5:23 PM Frank Ch. Eigler <fche at redhat.com> wrote:
>
> Hi -
>
> Thanks for reaching out!
>
> > The systemtap package is one that is particularly vulnerable to
> > changes in the kernel, and the older versions in stable releases
> > frequently see breakage with kernel updates or even when using a HWE
> > kernel, as you know.
>
> Right.
>
> > I don't personally use systemtap very often, but in talking to
> > coworkers my understanding is the 'latest' systemtap version can
> > almost always handle 'any' kernel that was previously released (i.e.
> > backwards compatible with kernels),
>
> That is correct.
>
> > but the systemtap library modules may not be backwards compatible,
> > so SRU'ing the latest systemtap might get it working with different
> > kernels but might also break user custom modules. Is that accurate?
>
> I don't think so - the whole system is designed to be aggressively
> backward compatible, and even includes runtime modes to disable newer
> functions for the benefit of older scripts.
hmm, if that's the case, then it might be even more appropriate to
just apply for a 'SRU exception' where the 'latest' version would get
pushed back to stable releases on a regular basis. That would be
certainly better than using backports, as users would get the newer
working version by default.
For reference, the sru exception process:
https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases
>
>
> > If so, maybe systemtap would be a good candidate for adding to the
> > -backports pocket; since it's an opt-in pocket, users would have an
> > option of getting the latest working systemtap on stable releases.
>
> Sorry, I'm not sure what the implications of this would be. If the
> effect is to make it easy to frequently update from upstream releases,
> that'd be great.
So the options are essentially:
1) the default process, of patching old versions one-bug-at-a-time
2) the SRU exception process, of pulling the entire 'latest' version
back into older releases
3) the backports process, of pulling the entire 'latest' version into
a special opt-in pocket of older releases
Backports aren't intended to actually fix bugs, but I had thought it
might be appropriate for systemtap; however, if the latest systemtap
versions really are backwards-compatible, the SRU exception process
would be the most appropriate way to get the stable releases updated.
>
>
> > This isn't a pre-approved notice, so if you think it's a good idea
> > (meaning you would be the one preparing and uploading the backports),
> > we (the backports team) can have a bit more discussion to make sure we
> > agree it's appropriate. [...]
>
> I'm not sure I'm personally in a position to undertake ubuntu
> packaging, but perhaps someone from our team or the community at large
> can make it happen. We can ask around if you need us to.
Certainly understandable, Ubuntu/Debian packaging isn't always the simplest ;-)
I cc'ed Emanuele Rocca, as the Debian maintainer, possibly would you
be interested helping maintain systemtap for stable Ubuntu releases? I
can also check with my team.
>
> (By the way, any idea whether y'all might put up a ubuntu debuginfod
> server, like debian (via sergiodj), fedora, and others have? It makes
> systemtap and other debugging type tools much easier to use.)
Yes, I'd be quite interested as well in when sergiodj might be getting
to that for Ubuntu ;-P
Last I heard from him, he was going to try to get some time carved out
for it. It would be very useful for my team as well so it's possible
I/we might work on it too at some point.
Thanks!
>
>
> - FChE
>
More information about the ubuntu-backports
mailing list