[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: cartridge user dependencies in own package

On 11/22/2013 03:33 PM, Brenton Leanhardt wrote:
+++ Jason DeTiberus [22/11/13 16:29 -0500]:
On 22/11/13 16:19 -0500, Brenton Leanhardt wrote:
+++ Troy Dawson [22/11/13 15:12 -0600]:
For those that don't know, we currently have alot of what I call
"user dependencies" in our openshift-origin-cartridge rpm packages.
I will use openshift-origin-cartridge-perl as my example.
In order to install the ropenshift-origin-cartridge-perl pm you have
to have

httpd facter rubygem(openshift-origin-node)
openshift-origin-node-util mod_perl
perl-DBD-SQLite perl-DBD-MySQL perl-MongoDB ImageMagick-perl
gd-devel perl-App-cpanminus perl-CPAN perl-CPANPLUS
db4-devel rpm-build expat-devel perl-IO-Socket-SSL gdbm-devel

As you start reading through that requirement list you think to
yourself, "well of course it need those" ...
then you get to the Database entries and you think ... "Well, that
makes sense"
then you read some of the others and think ... "If you say so, I
guess we need them"
and then you read rpm-build and think ...  "What??  why does my perl
cartridge need to build rpm's"

I'd like to work on a change, and make a proposal.

Let's change the requirements of the cartridges to only require what
is needed to make the cartridge run.
All the other requirements, let's put into their own requirements rpm.

* openshift-origin-cartridge-perl

* openshift-origin-cartridge-perl-users

I don't want to do this until release 3 is done.  But I'd like to
get the groud work started for the change.  There are a couple
things that need to be decided.

1 - Should we do this?


2 - What would we call the new rpms?
-- openshift-origin-cartridge-<cart>-users ?
-- openshift-origin-cart-dep-<cart> ?

I would be curious what people would think of

In my mind one way to view this is "compatibility with OpenShift
Online" so that applications are portable.  There's more to being
compatible with Online than that, but if this is a feature we want to
support then having -compat packages seems reasonable to me.

I'm not sure if that is reasonably sufficient, especially if we only
want to support a subset of what is offered in online for
compatibility (mongo db libraries for example).

3 - Do we have just one big dependency rpm per cart, or should we
have several?
-- openshift-origin-app-dep-redmine ?
-- openshift-origin-lang-dep-ta-lib ?

This seems to me like it would cause an explosion of packages.

I think we need a reasonable comprimise between the two, possibly
-userlib and -userlib-optional ?

I like the idea of 'optional'.  That's just what they are.  They might
not always be libs so maybe just -optional would be best.

Sorry for the long period with not talking about this. Things got very busy before the holidays.

I like the idea of having two packages, one being more optional than the other. I was wondering about something like -recommended and -optional.

Let's use openshift-origin-cartridge-perl as our example.
What about if we had

Despite what we call it, here is what I think would be the breakdown.


Requires:      facter
Requires:      httpd
Requires:      mod_perl
Requires:      openshift-origin-node-util
Requires:      perl-App-cpanminus
Requires:      perl-IO-Socket-SSL
Requires:      rubygem(openshift-origin-node)

Requires:      perl-DBD-SQLite
Requires:      perl-DBD-MySQL
Requires:      perl-MongoDB
Requires:      db4-devel


Requires:      expat-devel
Requires:      gd-devel
Requires:      gdbm-devel
Requires:      ImageMagick-perl
Requires:      perl-CPAN
Requires:      perl-CPANPLUS
Requires:      rpm-build

Does this sound reasonable?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]