Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor RPM handlers and Reorganize Code for Linux targets #493

Draft
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

adamperlin
Copy link
Contributor

@adamperlin adamperlin commented Jan 8, 2025

This PR refactors the handlers for RPM targets to be methods on a distro config, almost identical to how the DEB targets work. For example, installing build dependencies, building and testing a package, installing in a container, and the like should not vary much between rpm-based distros, so the functionality has been made into methods that encode the functionality for all rpm distros.

As part of this change, the project structure was altered to nest functionality common to RPM targets under frontend/linux/rpm, and functionality common to deb targets has been moved to frontend/linux/deb. A DistroConfig interface common to both is under frontend/linux. The DistroConfig interface is meant to encode what kinds of functionality any new type of distro would need to provide, such that the generic handlers HandleContainer(DistroConfig) and HandlePackage(DistroConfig) can be used for distro/container and distro/<package> type targets.

Special notes for your reviewer:
Many of the changed files in this PR are simply renames or changes of a single import, so the number of substantively changed files is much less than the diff shows.

@adamperlin adamperlin force-pushed the adamperlin/refactor-rpm branch from d834e04 to 1ca8771 Compare January 8, 2025 19:38
@adamperlin adamperlin force-pushed the adamperlin/refactor-rpm branch from 1e3f133 to 0212f81 Compare January 9, 2025 18:05
@adamperlin adamperlin force-pushed the adamperlin/refactor-rpm branch from 3a81bef to 8fd0366 Compare January 9, 2025 18:38
ocispecs "github.com/opencontainers/image-spec/specs-go/v1"
)

type DistroConfig interface {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea here is to have an interface that would work across distros, even beyond rpm/deb based packaging. Right now though, it just conforms to what is needed for rpm and deb. There are a few things that don't fit perfectly here, in particular the need for an extra worker parameter for building an rpm container when it isn't needed for deb. The signatures are similar enough though that it seemed like an interface would be reasonable, but I'm definitely open to rethinking this if it's too much of a stretch.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still reviewing, but at a high level I think this makes complete sense.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll say the large interface makes me a little hesitant but it doesn't seem too bad here.
If we need to add something that can't conform to it then it'll just need to handle some of these higher level functions on their own.

Basically, SGTM.

@@ -0,0 +1,49 @@
package rpm
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code hasn't changed beyond method renames

func (cfg *Config) Handle(ctx context.Context, client gwclient.Client) (*gwclient.Result, error) {
var mux frontend.BuildMux

mux.Add("rpm", linux.HandlePackage(cfg), &targets.Target{
Copy link
Contributor Author

@adamperlin adamperlin Jan 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can use the root generic linux.HandlePackage for this, parameterized on the cfg


type PackageInstaller func(*dnfInstallConfig, string, []string) llb.RunOption

type dnfInstallConfig struct {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We only have a dnf install config and not a tdnfInstallConfig, since in Dalec thus far every option we use is both dnf and tdnf compatible. In the future as we add more distros, we may need to rethink this portion, but if we stick to only using the options that are the same between the two, then it makes our life easier!


}

func DnfInstall(cfg *dnfInstallConfig, releaseVer string, pkgs []string) llb.RunOption {
Copy link
Contributor Author

@adamperlin adamperlin Jan 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've split out the install methods between TdnfInstall/DnfInstall maybe prematurely, in case there are differences between dnf and tdnf. In particular, I'm not sure if the separate /import-keys.sh script is needed for dnf yet, since we haven't yet added distros that use dnf.

Copy link
Member

@cpuguy83 cpuguy83 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WDYT about moving the rpm/deb stuff into a top-level package like packaging/rpm and packaging/deb or even packaging/linux/rpm and packaging/linux/deb?

Likewise I think we can move all the targets stuff into a top-level package called targets.

@adamperlin
Copy link
Contributor Author

@cpuguy83 I am definitely open to that! I think splitting the targets and the packaging pieces out makes a lot of sense!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants