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

Re: cartridge user dependencies in own package




----- Original Message -----
> From: "Troy Dawson" <tdawson redhat com>
> To: "Brenton Leanhardt" <bleanhar redhat com>
> Cc: dev lists openshift redhat com
> Sent: Monday, January 6, 2014 3:21:50 PM
> Subject: 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]:
> >>>> Hello,
> >>>> 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
> >>>> requires:
> >>>>  rubygem(openshift-origin-node)
> >>>>  openshift-origin-node-util
> >>>>  mod_perl
> >>>>  perl-App-cpanminus
> >>>>
> >>>> * openshift-origin-cartridge-perl-users
> >>>> requires:
> >>>>  openshift-origin-cartridge-perl
> >>>>  perl-DBD-SQLite
> >>>>  perl-DBD-MySQL
> >>>>  perl-MongoDB
> >>>>  ImageMagick-perl
> >>>>  ...etc...
> >>>>
> >>>> 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?
> >>>
> >>> PLEASE YES.
> >>>
> >>>>
> >>>> 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
> >>> openshift-origin-cartridge-<cart>-compat.
> >>>
> >>> 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
> openshift-origin-cartridge-perl-dependancies-recommended
> openshift-origin-cartridge-perl-dependancies-optional
> 
> Despite what we call it, here is what I think would be the breakdown.
> 
> openshift-origin-cartridge-perl:
> 
> 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)
> 
> openshift-origin-cartridge-perl-dependancies-recommended:
> Requires:      perl-DBD-SQLite
> Requires:      perl-DBD-MySQL
> Requires:      perl-MongoDB
> Requires:      db4-devel
> 
> 
> openshift-origin-cartridge-perl-dependancies-optional:
> 
> 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?
> Troy

Well, sure, but call it -dependEncies please :)
BTW why is facter required? As I recall that pulls in a bunch of (non-SCL) mcollective stuff we shouldn't need...


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