while playing with PostgreSQL 9.6 and Katello, I realized that Katello has an Requires on both postgresql and postgresql-server without really needing those (the installer will take care of the DB for us). It seems these were added for Candlepin in the very first version of rubygem-katello.spec and then moved to katello.spec at some point.
Looking at the RPM itself, the only place where we use any PostgreSQL stuff directly is in katello-backup/katello-restore and that’s only psql, pg_dump and pg_dumpall. I’ve started ripping out the Requires and my cat is not burning yet.
On the PR, @ekohl correctly commented that the Requires on java-openjdk is miss-placed too, as it really belongs to the candlepin package. And that Requires does not even work properly, as we define:
Yeah, I’d probably agree. But there is nothing that actually requires candlepin-selinux (probably because it is not strictly required for CP to work). So maybe that one is fine in the katello meta package?
We have the following packages: foreman-selinux, foreman-proxy-selinux, katello-selinux, pulp-selinux and candlepin-selinux. It would be great to make it consistent - either installing all via our installer or making dependencies somehow. I think installer would be the best place, install only if SELinux is present and enabled.
Given Katello only supported Postgres at the time we required it so that it would install when you yum install katello (hence why its on the meta-package). This was also to allow for RPMs to have the traceability that RPM dependencies have. A user can know Postgres was installed because Katello required it.
Why do we require OpenJDK and what’s with the version restriction?
If we look first at what Candlepin requires we see that it has a dependency on java greater than 1.6. This means that Candlepin juts needs java – openjdk or oracle or whatever. Given Katello has restricted deployment paths, we only support openjdk for our Java version. The openjdk version restriction is due to this bug that is still an open issue for Candlepin. I’ve been informed that Candlepin 2.3 will support openjdk 1.8.
Why candlepin-selinux?
Who doesn’t love selinux! I don’t know why CP does not require candlepin-selinux directly.
Why squid?
Pulp does not require squid to function. Squid can be used by the Pulp streamer to enhance caching but is not required. The Katello project chooses to use squid to enhance the user experience thus falling to us to require it.
Why createrepo?
This could be removed now as pulp-rpm properly requires createrepo and this requires in our RPM is from a looooong time ago.
Thanks to alternatives just requiring a specific java package does not make the system use that version of Java. If an application needs a specific version, it should use the versioned path.
As for traceability, I agree this is a nice goal, but the installer will install more packages anyways (sry for the scrambled output, can’t tell yum to make the columns wider):
I think the RPMs should only require the minimal requirements to get katello working. Any customization like squid and *-selinux should be done via the installer. (or in the case of selinux katello-selinux could require candlepin-selinux, ect…)
The world of our deployments and how we think about things has changed. So I am OK with moving away from traditional RPM requirement models where they make sense. I know things like split deployments affect this as well. If my postgres is on another server why do I need to require it on my application server.
And this is the crux of the philosophical argument, given there is no right or wrong answer. Our original goals were to be opinionated and provide the simplest, and best experience out of the box for users. Which meant requiring and installing pieces that achieve that goal. What I think I hear is that more and more folks would prefer a relaxed set of requirements to allow for composibility.
So digging into this a bit further, javapackages-tools as of 2.0.0 updated to check for openjdk or java (the original bug was it only checked for java and openjdk packages had changed the version string to just say openjdk) and EL7 has a newer javapackages-tools that handles this. So by all reasoning we could drop this limitation.
“Foreman is a rails application. Therefore, anything that is supported under RAILS (sqlite, mysql, postgresql, …) can be used.”
But what might be better (a technique I used in the past) is to check in the %preinstall the rpm database for one of the supported database packages and then fail and throw an error if none is present. This won’t resolve the dependancy for the user, but will at least provide a friendly error to let the user know they need to choose some database software. While I know that the installer will take care of installing a DB for you, there are other methods of installing foreman. I’m hoping to create another in the near future, and this will better support that.
Speaking of which, it might be useful to review puppet dependencies. If we really want to drop puppet from the core and move it to a plugin (and I think we should) it would be useful to either remove these dependancies, or put them in a meta-package. This would allow users to do yum install katello-installer postgres (and that would have puppet dependancies) which would result in one popular stack or to do yum install katello-ansible mariadb which would not have any puppet dependencies, would allow for RPM packaging of ansible plugins and could install another popular stack. Ultimately, this could allow for more flexibility in deployment scenarios, while still keeping it user friendly. Installer maintainers would, of course have to provide sane defaults and good instructions… and the puppet/kafo installer could still be the default, but I think this could provide much better flexibility and support for alternatives.
I still think it’s a bad idea to require the database server. It should be possible to run the database on another server which means it’s not a file dependency. The best you can do is the client libs, but doing magic in %preinstall is not obvious and IMHO asking for hard to debug issues.
