Firefox, and pca vs. patch_cluster - SUN

This is a discussion on Firefox, and pca vs. patch_cluster - SUN ; 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 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Firefox, and pca vs. patch_cluster

  1. Firefox, and pca vs. patch_cluster

    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


  2. Re: Firefox, and pca vs. patch_cluster

    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

  3. Re: Firefox, and pca vs. patch_cluster

    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.

  4. Re: Firefox, and pca vs. patch_cluster

    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

  5. Re: Firefox, and pca vs. patch_cluster

    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/

+ Reply to Thread