When Will Tech Pubs Improve the Requirements List?

[Legacy User]

seriously. when?

 

 

Apache-based Server Preparations for Linux - CA Single Sign-On - 12.52 SP1 - CA Technologies Documentation

 

as you can see there, they stripped most of the information upon the rpms.

this is NOT an improvement.

this is a MASSIVE DETRIMENT

 

it is one thing to say "this is the minimum required" and give the full information, but what you keep doing is making it HARDER for us.

 

Given that i am being tasked with writing a requirements document for our internal clients, i have 2 choices:

 

1: wait for Tech Pubs to fix this

2: Open a case for Support to get me the actual requirements

 

Given that this has been going backwards as i work with tech pubs, i think i'll make yet another support case that will likely be shut down based on the fact support wants tech pubs to handle this and they apparently cannot.

 

BTW: here's the list with color that i tried to place in that note to them.

 

Red Hat 6.x

The installer and configuration wizards are 32 bit programs requiring the following 32 bit rpms

• compat-db-4.6.21-15.el6.i686.rpm
• compat-db42-4.2.52-15.el6.i686.rpm
• compat-db43-4.3.29-15.el6.i686.rpm
• compat-libstdc++-33-3.2.3-69.el6.i686.rpm
• compat-libtermcap.rpm
• libexpat.so.1 (provided by expat-2.0.1-11.el6_2.i686.rpm)
• libfontconfig.so.1 (provided by fontconfig-2.8.0-3.el6.i686.rpm)
• libfreetype.so.6 (provided by freetype-2.3.11-6.el6_2.9.i686.rpm)
• libICE-1.0.6-1.el6.i686.rpm
• libidn.i686.rpm
• libidn.so.11.rpm
• libidn-1.18-2.el6.i686.rpm
• libSM-1.1.0-7.1.el6.i686.rpm
• libstdc++.i686.rpm
• libstdc++-4.x.x-x.el6.i686.rpm
• libuuid-2.17.2-12.7.el6.i686.rpm
• libX11-1.3-2.el6.i686.rpm
• libXau-1.0.5-1.el6.i686.rpm
• libxcb-1.5-1.el6.i686.rpm
• libXext.i686.rpm
• libXext-1.1-3.el6.i686.rpm
• libXft-2.1.13-4.1.el6.i686.rpm
• libXi-1.3-3.el6.i686.rpm
• libXp-1.0.0-15.1.el6.i686.rpm
• libXrender.i686.rpm
• libXrender-0.9.5-1.el6.i686.rpm
• libXt-1.0.7-1.el6.i686.rpm
• libXtst.i686.rpm
• libXtst-1.0.99.2-3.el6.i686.rpm
• ncurses-5.7-3.20090208.el6.i686.rpm
• ncurses-base-5.7-3.20090208.el6.i686.rpm
• ncurses-libs-5.7-3.20090208.el6.i686.rpm

Notes:

Blue Text is under investigation by CA for reason of the package is seemingly unavailable in 32 bit

Red Text is under investigation by CA for reason of the package name does not follow standards

 

as stated in the note to them on that page, there's actually one i skipped over that they should also get right.

 

thank you CA Tech Pubs for creating work for your Support Team.

[Ujwol]

Josh, didn't we have a thread discussing the same topic a while back ?

[Legacy User]

possibly. but my last correspondence resulted in making things worse. it seems they did not understand, so i am trying to pull in the community to show them these changes are the wrong direction.

[Mark ODonohue]

Hi Josh, as you can appreciate the wheels can turn slowly at time, particularly when the first cut did not resolve the underlying issue.  Gayatri is working with Engineering to get what they believe is the correct response and she will document that.  

 

As per the last request, while it sounds simple question, the "supported" answer has some real twists to it.   Redhat have a nice X.X.X.X-Y version number system, but not everyone uses that definitions for binary "compatible" releases.   Even Redhat mess it up in a few cases.

 

My current take on it is the document should specify the actual rpm packages that are used for the release but with note at the bottom that we support the latest security patches for that release of the OS.

 

Cheers - Mark

[Legacy User]

Format of the RPM File

 

there is a standard name format.

 

from the link: name-version-release.architecture.rpm

 

added to that, they dropped to just the name on most, which hurts,

 

there should be a list of "required packages at the earliest supported revision" like other companies do, because this allows you to verify you have the minimum necessary. not giving that is a disservice.

 

added to that, as pointed out some of these are the library, not the package we should use to attain the version you want.

added to that, some of these are duplicate listings.

 

when i was there and a client needed this i was asked if i could expedite the process. Rick and i were able to find most in 2 weeks. wasnt perfect but it was better than they have now. they never followed up. they never finished the work.

 

now it is hurting me as a client.

 

they've been working on this for a good year before i left CA. and i've been gone what, 3 years? that means 4 years and they dont have something yet?

 

that's not slow, that's not caring about the clients they have.

 

i know the support does. why else would there be the push for people like you and, wheni was there, myself, creating and supplying items like the readers and other tools.

 

at this point it feels like docs just doesn't care.

 

maybe they need to have their pay dependent on your case load... hold 1 tenth of their pay. if you support people have the case load go up disporpotionately to the clients going up, they dont get it. if it goes down, they get extra... maybe more than 10%

 

that would give them a good incentive to have solid docs.