When will the Documentation Team correctly Document Requirements?

[Legacy User]

example of how this  is not correct: Apache-based Server Preparations for Linux - CA Single Sign-On - 12.52 SP1 - CA Technologies Documentation

 

currently lists the following:

 

• libidn.so.11
  • This is a Library, not an RPM. your list is supposedly RPMs and you would have to give providing RPMs even if you move to libraries
• libstdc++-4.x.x-x.el5.i686.rpm
  • this is invalid as the version number is  replaced by "x.x-x"
• libidn.so.11.rpm
  • invalid RPM format. looks like a failed attempt to explain the library above
• libXext.i686.rpm
  • invalid format, no version informaiton

 

i hope  i dont have to go on and call them all out individually to  get them corrected, but this is not what i would expect from a vendor wanting to win the market. if you cannot give us the correct requirements, how can we be sure  you wont play games if there is a problem and claim we did not have the right requirements?

 

i know there are open tickets on this. i also know there is zero traction on them

tech pubs, when will you fix these?

[Ujwol]

Hi Josh,

Have you tried putting comment in the docops for correction request?

[Legacy User]

i have tried tickets, wikki comments, i just dont know how to get them to do more than take note and not do anything.

 

i am resorting to publlic outcry hoping others will want them to get these corrected so that they realize it IS something they need to care about.

[Karmeng]

Hi Josh,

Thanks for your input. I have put in the comment in docops (12.52SP1 and 12.52SP2) for documentation team to follow up. I agree that the Require Linux libraries portion is confusing due to the incorrect file name provided.

This definitely need to be corrected and I appreciate your contribution.

 

Regards,

Kar Meng

[Legacy User]

Kar, i would love to leave your answer correct, but the doc team made things worse. this shows they dont understand the issue.

[Gayatri.Mothey]

Thank you for your feedback, Josh.

We worked with the engineering team and reviewed the content. The team suggested that we list only the major versions of the libraries and remove the RPM usage. We updated the content accordingly for Policy Server, Administrative UI, and Web Agent for Apache in CA SSO 12.52 SP1, please have a look and let us know if you have any further questions.

We are in the process of updating the Linux libraries of other components and versions in the CA SSO suite.

 

Regards,

Gayatri

[Legacy User]

If you remove the RPM to use, how will wee know which RPM has the Library you used?

 

will you support any rpm that provides that library?

 

also, you still have some listed as the .so, the library itself, not the providing package.

 

you are only partially addressing this, and not even addressing well from what i can tell.

 

Are you trying to create more calls for Support or less? the changes i see so far are going to generate MORE calls.

[Legacy User]

i am calling you out again on the mistakes.

 

your library fix fixed nothing.

you now state any revision of the RPM will work. so what happens if someone ends up on a level too low?

not only that, you still have libraries instead of packages listed. congrats! you don't understand thee issue and your fix addressed NOTHING.

 

 

Proof: libidn.so.11

More Proof: repeated libraries with differing information still exists

[Patrick Dussault]

Hi Josh,

 

That will not tell you when the documentation will be written correctly, but you might try this command and adjust if needed to install all of them :

 

 

# for i in libstdc++ libXau libxcb compat-db42 compat-db43 libX11 libXrender expat libfreetype libfontconfig libICE libuuid libSM libXext compat-libstdc++ compat-db libXi libXtst libXft libXt libXp; do yum -y install $i.i686 ;done;

 

I think latest version should have some needed.

 

Hope that might help,

Patrick

[Legacy User]

Patrick, that does not help.

my issue is the potential redundant lines and the flat out incorrect lines.

 

if you support and level of the package that is fine, but you cant claim an SO is an RPM.

 

 

could someone at CA please go take a linux admin course?

it feels like you have no one who has ever seen linux.

[Ujwol]

JoshPerlmutter,

 

If you look at my first comment , I specifically asked if you have put your comment in docops. For 12.52SP1 and 12.52SP2 the documentation is now maintained in docops.ca.com.

 

The link that you provided in your OP, itself is from docops.ca.com. Unfortunately, I don't see your comment in that link.

I believe your current post would have been more helpful, if it was made to the docops directly. As, any comment in docops is monitored by our techpub team and are acted upon as quickly as possible. Sometime there might be delays, as they do not have the technical background, they might have to go back to development/product management before getting approval for the change.

 

Now coming to inaccuracies. Yes , there are some inaccuracies and they will be be corrected over the time based on the feedback from our customers, engineers, supports etc.

 

As far as the direction we are moving forward about requirement specification, as Gayatri said, the plan is to specify only the library along with the minimum major version that is supported. e.g. libstdc++-6

 

Now here, I don't think there is ANY need to specify .so extension (or any harm if .so extension is provided)  as that should be self explanatory when we say library. This would also mean that  libstdc++-6.x.x would be supported.

 

and, YES, we will be supporting ANY rpm providing these libraries.

 

Hope this clarifies few of your concerns if not all.

 

Cheers,

Ujwol Shrestha

[Legacy User]

judging from your response, like them, you do not understand the difference between a SO and a RPM

[Ujwol]

Please educate us then.

[Legacy User]

That is something CA should budget for. they need people that understand the systems they have products running upon

[Ujwol]

Awesome. Thank you for your insights.

[Mark ODonohue]

Hi Josh, Gayatri is continuing to work with the Engineering build team to update the dependencies in the documentation.  There is a tradeof here in that we support bugfix releases of the rpm packages for Redhat so specifying the exact rpm used at build time isn't always the same as what is supported.   But usually the <major>.<minor> version numbers are appropriate as they specify no change in the binding interface.  The two lower numbers are usually <bugfix> and <buildnum> and we generally support latest ones of those.   Of course the Redhat version scheme (or maybe it is defined in Linux Standard Base) isnt followed by all the package maintainers, so there are always some tricky ones eg: ncurses-libs-5.7-3.20090208.el6.i686.rpm  and even the various Redhat compat packages  compat-db43-4.3.29-15.el6.i686.rpm, compat-libstdc++-33-3.2.3-69.el6.i686.rpm where that do not fit the mould and need a bit of extra consideration.

 

I'll send you a note when she updates them in the docops directory and you can have a look over them.

 

Cheers - Mark

[Legacy User]

THank's mark.

 

please talk to Pete, my DSE.

there are cases open since STAR on this.

there have been many emails to Pete with exact details, as well as to the tech pubs directly.

nothing has resulted in proper corrections.

 

I know it's not Pete trying, he's the one that got me TECH PUBS email alias to get them the details.

 

the fact they still don't understand library (so) v providing package (rpm) is alarming.