Missing package in proxy repo for FDI build

Hello @packaging !

I am missing a package in 1.18 plugins EL7 repo which prevents me from bulding FDI 3.5 release.

The rest is present:

It is in nightly, so perhaps some whitelisting issue?

Thanks

The fast_gettext moved to foreman folder in packaging and the package is available in releases/1.18/el7/x86_64/tfm-rubygem-fast_gettext-1.4.1-2.el7.noarch.rpm.

The foreman discovery image needs a a non-SCL version of it. I wonder if we should package the UI so we’ve documented why we have rubygem-new and rubygem-fast_gettext packages in our repo.

I’d like foreman-discovery-image metapackage instead requiring all the four packages instead. Building RPMs to do FDI scratbuild is insanely slow workflow.

This is still an issue, I am unable to build new FDI.

I am going to create new metapackage foreman-discovery-image-tui which will require all dependencies so this does not get deleted from plugin repos. It happened three times during packaging “cleanups” recently. I don’t want to move the code itself into the package yet.

I created a PR to return it back first, not sure if it works tho, tests are green tho: https://github.com/theforeman/foreman-packaging/pull/2857

It would be good if the FDI UI would be packaged as a gem and followed our regular release schedule. I imagine that could also simplify the kickstart a bit. Would that be feasible and how hard would it be?

Technically it is possible but I prefer to track this in my TODO for now as there are planned changes in TUI in the near future. Having it as RPM dependency makes the build process extra challenging - RPMs need to be signed before ISO image can be built. Doing scratchbuilds is also a nightmare - you need to create an extra repo, add it to brew or modify build process.

However long term, yes that’s the goal. TUI is not the only component that needs a package - there are many scripts and tools around that need to be in RPMs as well. I would like to improve the build process first upstream and downstream, it’s been rather chaotic last couple of releases.

To prevent dropping dependencies, I propose to create a metapackage for now. The metapackage can be turned to regular package in the future easily.

A metapackage would help a lot. It would prevent us from removing “orphaned” dependencies.

Absolutely.