Initial stub out for different kernel packages per distro

[jcpunk]

This sets up a skeleton for how multiple "kernel" packages might be checked on hosts that have alternate kernels installed (kernel-rt or kernel-ml) and tries to track updates of the alt kernel rather than the stock kernel.

This passed my minimal smoke test, but I wouldn't call it release ready...

I got lucky that each package manager's search result object has a .name attribute :)

I do wonder if there is any value switching those to @staticmethod since they just pop off an object attribute?

On the kernel package name front, I wonder if those should just land in the applications.xml file as a new type of thing rather than hard coded here?

I still have no idea how to handle "debian" style kernel package names...

[FrostyX]

Thank you for the PR @jcpunk,

I got lucky that each package manager's search result object has a .name attribute :)

Hehe, I haven't seen the code for a long long time, but I think it wasn't luck, and possibly they are all instances of

tracer/tracer/resources/package.py

Line 22 in a6bbdfd

class Package:

If yes, we probably won't need the package_name_only abstraction.

But otherwise the change looks good to me.

I still have no idea how to handle "debian" style kernel package names...

I don't either, but I wouldn't consider it a blocker. We can merge it if the feature works well on Fedora/RHEL and anyone can contribute the support for Debian later.

Also, @jcpunk, since you are the most active contributor these days, would you like a commit access to the repository?

[jcpunk]

It seems to work alright for my test hosts, but I wouldn't mind more testing.

I'm fine with using a github fork and sending PRs as I get time/inspiration.