SEO

I tried to install firefox 2.0.0.14 on Solaris 8 Sparc last week, and it
would not run. This is the distribution put together by Sun's folks in
China. This version of firefox wants these Solaris patches:

[0]="108434-17" "32-Bit Shared library patch for C++"
[1]="108435-17" "64-Bit Shared library patch for C++"
[2]="108652-79" "X11 6.5.1: Xsun patch"
[3]="108773-18" "SunOS 5.8: IIIM and X Input & Output Method patch"
[4]="109147-27" "SunOS 5.8: linker patch"
[5]="109159-03" "SunOS 5.8: Chinese iconv module updates"
[6]="109704-03" "SunOS 5.8: Japanese iconv patch"
[7]="111721-04" "SunOS 5.8: Math Library (libm) patch"
[8]="113261-02" "SunOS 5.8: UTF-8 locale ICONV patch"
[9]="114542-01" "SunOS 5.8: Adds extended Arabic support"
[10]="111721-04" "SunOS 5.8: Math Library (libm) patch"

At least some of those are really needed, since bypassing the patch
checker resulted in firefox sort of starting and then exploding.

So as an experiment today I compared three "automatic" patch retrieval
methods: pca --askauth -d all (with and without service contract
access) and the current patch cluster (with service contract access).
The idea was to see if any of these would put the system into a
configuration which would let Firefox run without manually downloading
the required patches from the list. The number of patches retrieved was
very different:

[A] pca (no serv. contract) 318
[B} patch cluster (w. serv. contract) 206
[C] pca (w. serv. contract) 530

Comparing the entries in the first two showed a lot of overlap, but
there were entries in each that were not present in the other. For
instance, 108569-08 was in PCA and 108576-52 was in the patch cluster.
1085690-08 is "X11 6.4.1: platform support for new hardware" which is
roughly correct (the hardware for this system is included) but not
really needed (there is no graphics "head" on the system.) 108576-52
is "SunOS 5.8: Expert3D IFB Graphics Patch" which is related to the
SUNWifb package, which is not installed on this system either.

More to the point, for the patches required for firefox to work:

patch [A] [b] [C]
[0] + + +
[1] + + +
[2] + - + (108652-98 obsoleted by 119067-01)
+ + + (119067-09)
[3] + + +
[4] + + +
[5] - - -
[6] - - -
[7] + + +
[8] - - +
[9] - - -
[10] + - +

I think it will be ok to skip patches 5,6,9 so long as a I never
hit Asian or Arabic language sites, and start firefox with

export MOZILLA_SOLARIS_PATCHCHECKER=disable_patchchecker

I'm not quite sure what the base package is for those patches, although
it appears that it may be iconv. The patched files are not currently
present on my system.

The absence of patch 8 in the non service contract pca list was odd.
It might have been a glitch. Hope so. Otherwise folks without a
service contract are not going to be able to run this version of Firefox
on Solaris 8.

For patch 2 PCA correctly picked up the final patch in the chain, but
for some reason also kept the final patch in the series before the patch
number changed. Perhaps that is a bug in pca.

So, it looks like PCA does get more of the patches that are needed for
firefox than the patch cluster does. At the expense of downloading 2.5X
more patches, and at least one which is obsoleted by another patch it
also downloaded.

Regards,

David Mathog

David Mathog wrote:

> I think it will be ok to skip patches 5,6,9 so long as a I never
> hit Asian or Arabic language sites, and start firefox with
>
> export MOZILLA_SOLARIS_PATCHCHECKER=disable_patchchecker

This turned out to be the case. I have run firefox for a while
now and the absence of Asian language support has not yet
caused any issues.

Regards,

David Mathog

David Mathog wrote:
> David Mathog wrote:
>
>> I think it will be ok to skip patches 5,6,9 so long as a I never
>> hit Asian or Arabic language sites, and start firefox with
>>
>> export MOZILLA_SOLARIS_PATCHCHECKER=disable_patchchecker
>
> This turned out to be the case. I have run firefox for a while
> now and the absence of Asian language support has not yet
> caused any issues.
>

Would you expect it to?

I occasionally get spam in Arabic, Japanese, Chinese. I couldn't read
it anyway so it doesn't matter if my browser and/or mail client can
render it.

Richard B. Gilbert wrote:
> David Mathog wrote:
>> David Mathog wrote:
>>
>>> I think it will be ok to skip patches 5,6,9 so long as a I never
>>> hit Asian or Arabic language sites, and start firefox with
>>>
>>> export MOZILLA_SOLARIS_PATCHCHECKER=disable_patchchecker
>>
>> This turned out to be the case. I have run firefox for a while
>> now and the absence of Asian language support has not yet
>> caused any issues.
>>
>
> Would you expect it to?
>
> I occasionally get spam in Arabic, Japanese, Chinese. I couldn't read
> it anyway so it doesn't matter if my browser and/or mail client can
> render it.

The question is (and it is not yet resolved) whether the code would know
"that library doesn't exist" and not try to render those languages, or
if it would assume that the library does exist, try to render using
bogus pointers and such, and boom. Normally I would assume that since
support for various languages is optional a program would do the former,
but in this case since the patch checker which ships with Sun's firefox
port demands those extra patches, I wonder if it might not do the latter.

Regards,

David Mathog

David Mathog wrote:
> So as an experiment today I compared three "automatic" patch retrieval
> methods: pca --askauth -d all (with and without service contract
> access) and the current patch cluster (with service contract access).

Be aware that the "all" patch group contains both missing patches and
patches which are already installed on your system. If you want to
list/download/install missing patches only (which makes a lot of sense),
use the "missing" patch group with pca; this is the default if no patch
group is specified.

> Comparing the entries in the first two showed a lot of overlap, but
> there were entries in each that were not present in the other. For
> instance, 108569-08 was in PCA and 108576-52 was in the patch cluster.

The approach used by pca to determine missing patches is actually quite
simple - it shows all patches which are for packages installed on the
system, not more and not less. Behind the scenes, it handles some
patches in a special way though, as the patch metadata in patchdiag.xref
often is incorrect.

> 1085690-08 is "X11 6.4.1: platform support for new hardware" which is
> roughly correct (the hardware for this system is included) but not
> really needed (there is no graphics "head" on the system.) 108576-52
> is "SunOS 5.8: Expert3D IFB Graphics Patch" which is related to the
> SUNWifb package, which is not installed on this system either.

To determine whether pca is correct is usually quite simple - just try
to install the patch. pca used Sun's patchadd, and if it installs the
patch then it obviously is fine. If a patch shown in pca's missing list
doesn't install, that's a bug; feel free to report it. The above example
shows that pca is correct.

> I think it will be ok to skip patches 5,6,9 so long as a I never
> hit Asian or Arabic language sites,

5,6,8,9 are not shown by pca because you do not have the packages for
these locales installed, so the patches are not needed either.

In my experience, firefox always worked fine without these
packages/patches; I had disabled the patchchecker in firefox as well to
get rid of the warnings.

> I'm not quite sure what the base package is for those patches, although
> it appears that it may be iconv. The patched files are not currently
> present on my system.

You can find out about the patch<->package relation by looking at
patchdiag.xref, or by unzip'ing the patch zip file and looking for the
SUNW* directories included.

> The absence of patch 8 in the non service contract pca list was odd.
> It might have been a glitch. Hope so. Otherwise folks without a
> service contract are not going to be able to run this version of Firefox
> on Solaris 8.

113261-02 is not a Security patch, so it's probably not available for
non-contract customers. I don't think that it really breaks firefox, though.

> For patch 2 PCA correctly picked up the final patch in the chain, but
> for some reason also kept the final patch in the series before the patch
> number changed. Perhaps that is a bug in pca.

See above - don't use "all".

If you want to download/install exactly those patches which apply to
your system, PCA really is the way to go. With the clusters, you will
always download patches which do not apply to your system or which are
already installed.

Hope that helps,

mp.
--
SysAdmin | Institute of Scientific Computing, University of Vienna
PCA | Analyze, download and install patches for Solaris
| http://www.par.univie.ac.at/solaris/pca/