On 2 August 2016 at 16:33, Pete Helgren <pete@xxxxxxxxxx> wrote:
I don't think the problem is the method, it is the documentation. PTF cover
letters are like EULA's to me: You glance at 'em and move on.
Exactly this.
Dr Franken's simple instructions to install all 15 options was my Aha!
moment. Knowing that the _LPP is really the EULA_ and that the
functionality is in the paperwork made all the difference to me.
For those of us like me who simply install /all/ the OPS options,
every time new ones come out, this is probably easy. For those who
have to justify every bit of stuff that gets loaded, this mechanism
needs just a little better documentation. If I could edit the DW wiki
page on OPS, I would. My suggestion is to have a simple side by side
table that looks like this:
Python 3.4.4 5733OPS Option 2 Mandatory PTF SI59051
ibm_db 2.0.5.4 5733OPS Option 2 Mandatory PTF SI60563
... and so on.
The key thing is to plant in my dumb head the idea that I need to put
the OPS option on, and also put on ONE PTF for that option. That one
PTF will have all of the co- and pre-reqs, so in the case of Python 3,
there would be one 'base' or 'marker' PTF that would pull all of the
Python 3 functionality and fixes in one request. That way, if I
decide I only want Python 3 I wont accidentally install pieces/parts
of Python 2.
I would have done this exact thing in the Midrange wiki but I have not
done the research yet to deduce which of the various PTFs should be
designated as the one which will pull down all the functionality for
which option.
--buck
midrange.com
