search

neoave / mrack

Multicloud use-case based multihost async provisioner for CIs and testing during development
Apache License 2.0
11 stars 14 forks source link

feat: Split mrack into multiple rpms #190

Closed Tiboris closed 1 year ago

Tiboris commented 1 year ago 
Splitting mrack to:
- mrack
- mrack-cli
- python3-mracklib
- python3-mrack-aws
- python3-mrack-beaker
- python3-mrack-openstack
- python3-mrack-podman
- python3-mrack-virt

where python3-mracklib contains only static provider and all the
scripts and provisioning base logic.
we can install mrack-{aws,beaker,openstack,podman,virt}
providers in addition to static provider extending
the functionality and create modular solution where only
needed providers can be installed.
Package mrack contains all supported providers.
Package mrack-cli contains mrack command.
We are using Suggests directives for OpenStack dependencies
so in fedora where these are not available build will pass.

Resolves: https://github.com/neoave/mrack/issues/113

This MR depends on:

Tiboris commented 1 year ago

@praiskup Would you mind having a look here?

praiskup commented 1 year ago

So previously there was just mrack, and also the mrack package stays here ... serving the same purpose as before, bringing in all the new deps. So you don't have to do any artificial dependency "obsoletes" hacks or so, good (you just update to an updated mrack.rpm, and all the deps will be installed automatically). Overall it looks fine to me.

Tiboris commented 1 year ago

@pvoborni do we want the mrack-cli package? it would contain mrack script only

Tiboris commented 1 year ago

Right now the packages should reflect this dependency graph:

└─             mrack   
                     └─  mrack-core (Static)    
                     └─ mrack-aws
                     │     └─  mrack-core (Static)    
                     ├─ mrack-beaker
                     │     └─  mrack-core (Static)    
                     ├─ mrack-openstack
                     │      └─  mrack-core (Static)   
                     ├─ mrack-podman
                     │      └─  mrack-core (Static)   
                     └─mrack-virt
                               └─  mrack-core (Static)
pvoborni commented 1 year ago

I never wanted "mrack-cli" package. I thought the idea was to have:

So what happened to the mrack-all and python3- prefix?

praiskup commented 1 year ago

mrack-all (virtual package which requires all providers in this repo packaged for given OS)

This sounds doable? Not the most common and natural pattern, you e.g. need to take an explicit care of the upgrade path (Obsoletes etc.). But overall looks like OK to me as well (IMVHO a matter of taste).

Tiboris commented 1 year ago

@praiskup does it make sense to have mrack-core as a dependency of mrack if it is already transitive of each dependent package?

praiskup commented 1 year ago

does it make sense to have mrack-core as a dependency of mrack

@Tiboris technically it is not necessarily, when the main (mrack or mrack-all) package is only supposed to be a "metapackage". If not a metapage (== contains at least some files that depend on core) it is better to stay explicit (even though the dependency could already exist implicitly, generated by rpmbuild itself ... I'd have to test).

praiskup commented 1 year ago

So what happened to the mrack-all and python3- prefix?

+1 for python3- prefixes

Tiboris commented 1 year ago

@pvoborni I have fixed the python prefix and updated spec file to reflect things we agreed on in our discussion, shortly:

Splitting mrack to:

@praiskup I hope that the python prefix is fine now I did not find any directive for such prefix thus i hard-coded it did i tried poorly (to find the directive)?

Tiboris commented 1 year ago

Also I have updated README.md to suggest installation steps when only a subset of functionality is required.

Tiboris commented 1 year ago

PR is ready for review.

praiskup commented 1 year ago

@praiskup I hope that the python prefix is fine now I did not find any directive for such prefix thus i hard-coded it did i tried poorly (to find the directive)?

No, seems fine - python3- prefix is usually hard-coded in every %package, %description, %files tag....

praiskup commented 1 year ago

looks fine to me