chef-workstation RPM warns of missing dependencies, probably needs refactoring about chef-workstation

[jonsmorrow]

Thanks for the report. The team is busy with some other priorities but I'll make sure we look at this when we get back to it.

[tyler-ball]

Hey @bby-bishopclark - you are right that this is an issue, and thank you for reporting. We made a decision in our *nix distributions to not include all the x-windows deps by default for users who wanted to install Chef Workstation on CI nodes. Our plan in the future is to produce a Chef Workstation package intended for install on user workstations (which would include the x-windows dependencies) and a separate 'Chef CI' package intended for CI/pipeline usage that would not need windowing. But thats a longer term project and is not on our roadmap yet. When we get that project added to our roadmap we will circle back to this issue.

[bby-bishopclark]

Thus the refactoring need. When it becomes valuable again, remember that standard practice is to split optional pieces into optional packages. It's quite seriously THE method for handling that given problem. You'll notice it in packages like

dbus-x11.x86_64 : X11-requiring add-ons for D-BUS
setools-gui.x86_64 : Policy analysis graphical tools for SELinux
net-snmp-gui.x86_64 : An interactive graphical MIB browser for SNMP
cinnamon-desktop.x86_64 : Shared code among cinnamon-session, nemo, etc

If a minimal bare package is valuable to the CI nodes, that simply becomes your base package, on which the optional pieces can be layered in. It's how United did it, Open before that, and RHL before that -- but now we're going back to 1996.

I think bringing the packaging up to those standards is a good thing, but of course priorities are what they are. Given the licensing change, and how it can potentially affect both my jobs, I'm not sure whether this will stay a priority for me; but I'll try to put some time into it if I get the ancillary details cleared and the time awarded.

[marcparadise]

I think this postinstall output is helpful if you have just a couple of missing deps, and looks like something has gone really wrong in any other case.

I recommend that we replace that output with something like:

The Chef Workstation App cannot be run because of missing dependencies. 
For more information, see https://docs.chef.io/appropriate_pre_req_link_here. 

I'm a little concerned with the phrasing of even that, though. A quick skim might parse as "Workstation can't be run because of dep issues".

[marcparadise]

@bby-bishopclark I agree that separate packaging is the best way to handle this, as it would allow us to better manage these situations; but to keep build and distribution complexities down we're unlikely to take that approach.

Another option that I think I like more than the message change above would be to generate a first-run wrapper around the App on linux. That wrapper could then check pre-reqs and recommend a package to install to enable it.

[bby-bishopclark]

to keep build
The build process is still rpmbuild -ba .

and distribution complexities down
The yum repo is configured identically.

generate a first-run wrapper

This threatens the single source of truth that's inherent and crucial to a sane Enterprise system. If the package still installs atomically without this OOB script killing it halfway-through - which is a fine mess - then the OOB script usurps authority over dependencies and installation state. Loan sharks could beat the rate which which this technical debt will accumulate, all for the reluctance to create a sub-package like we've done since last millennium.

But that's why it's best practice to do it properly. Your wallet, your decision.