Yuriy,
- you should indent the scriptlets in your specfile. They
are difficult to read otherwise
- you should have a %changelog section
(with 1 entry - "initial version")
- is there really no version number attached to most of the
source filenames? Are these files likely to be
-line 175:
install -d $RPM_BUILD_ROOT%_myspelldir
(& lines 191, 197, 204) - should these be outside the "for" loop?
Regards,
Dermot
Yuriy Kuznetsov wrote On 05/01/07 16:21,:
> Hi All,
>
> G11n team is requesting review of SUNWmyspell-dictionary.spec(see
> attached) which would build the following packages :
>
> SUNWmyspell-dictionary-cs
> SUNWmyspell-dictionary-de
> SUNWmyspell-dictionary-en
> SUNWmyspell-dictionary-es
> SUNWmyspell-dictionary-fr
> SUNWmyspell-dictionary-hu
> SUNWmyspell-dictionary-it
> SUNWmyspell-dictionary-pl
> SUNWmyspell-dictionary-ptBR
> SUNWmyspell-dictionary-ru
> SUNWmyspell-dictionary-sv
> SUNWmyspell-dictionary-extra *
>
> * SUNWmyspell-dictionary-extra package will include foloowing
> dictionaries : ca_ES, da_DK, el_GR, he_IL, nb_NO,
> nl_NL, sk_SK, sl_SI.
>
>
> - These packages provide spell dictionaries for common dictionaries
> between GNOME, Evolution, Firefox, Thunderbird and StarOffice.
> - ARC fast track was sent by Irene Huang(Irene.Huang at Sun.COM), Harry
> Lu(Harry.Fu at Sun.COM) and now under the review(see attached).
> - SUNWmyspell-dictionary.spec is planned to integrate in
> vermillion_65/snv_65.
> - Currently Firefox and Thunderbird have the dictionaries in the
> packages and we move those dictionaries to this package.
> - We provides dict symlinks in this package for Thunderbird, Firefox
> because FF/TB needs the filename format of "xx-XX" but enchant needs
> the filename format "xx_XX" and All dict related symlinks are in this
> packages.
> - SUNW_PkgList has SUNWgnome-spell and SUNWthunderbird but not
> StarOffice at the moment.
>
>
> Thanks in advance,
> yuriy
>
>------------------------------------------------------------------------
>
>This information is
>Sun Proprietary/Confidential: Internal Use Only: Engineering Need-to-Know
>Copyright 2006 Sun Microsystems
>
>1. Introduction
> 1.1. Project/Component Working Name:
> Sharing Dictionaries for Spell Checking On GNOME
>
> 1.2. Name of Document Author/Supplier:
> Harry Fu
>
> 1.3. Date of This Document:
> 04/19/07
>
> 1.4. Name of Major Document Customer(s)/Consumer(s):
> 1.4.1. The PAC or CPT you expect to review your project:
> Solaris PAC
> 1.4.2. The ARC(s) you expect to review your project:
> PSARC
> 1.4.3. The Director/VP who is "Sponsoring" this project:
> Mimi.Hills at sun.com
> 1.4.4. The name of your business unit:
> SLE-Globalization
>
> 1.5. Email Aliases:
> 1.5.1. Responsible Manager: Young.J.Song at Sun.COM
> 1.5.2. Responsible Engineer: Harry.Fu at sun.com
> 1.5.3. Marketing Manager: N/A
> 1.5.4. Interest List: desktop-g11n at sun.com
>
>
>2. Project Summary
> 2.1. Project Description:
> The proposal is to move the current dictionaries used by
> Thunderbird for spell checking to a common place, so that Evolution,
> Gedit and other applications can employ these dictionaries via project
> Enchant
> (see section 5).
>
> The current /usr/lib/thunderbird/dictionaries/*.{dic.aff} will be
> replaced by symbol links pointed to
> /usr/share/spell/myspell/*.{dic,aff}.
>
> 2.2. Risks and Assumptions:
> Spell checking function is not available on a system without GNOME
> installation (like S8, S9). However, it is confirmed with baseteam
> that the
> focus is on Nevada and system without GNOME installation is not
> considered
> (since there is no evolution, no mozilla etc.). Thus, the common
> dictionaries
> can be maintained and delivered together with GNOME l10n pkgs.
>
> If a user installs earlier L10n package, the dictionaries will be
> placed under /usr/lib/thunderbird/dictionaries/, and sysbol links will
> be
> replaced. But it won't break the spell checking functions.
>
> Users can also install/uninstall dictionary extensions(addons) from
> Thunderbird community. Those dictionaries will be placed in the user's
> home
> directory by Thunderbird, thun hava no impacts to the common
> dictionaries in
> question.
>
>
>3. Business Summary
> 3.1. Problem Area:
> To use the free dictionaries currently shipped with Thunderbird by G11n
> to accommodate Enchant to provide spell checking for other GNOME
> applications.
>
> 3.2. Market/Requester:
> JDS team
>
> 3.3. Business Justification:
> The Desktop Cteam has decided to EOL aspell in GNOME 2.18 and use
> enchant. This is also reflected in GNOME 2.18's ARC case and has been
> approved.
> Though enchant can support multiple backends such as aspell, myspell
> and uspell,
> they decided to support myspell backend only in JDS so that GNOME
> components and
> mozilla components can share the same dictionaries. G11n has shipped
> the myspell
> dictionaries in nevada, and we will continue to ship them, but to a
> common
> directory.
>
> 3.4. Competitive Analysis:
> The usability of JDS will be enhanced.
>
> 3.5. Opportunity Window/Exposure:
> In GNOME 2.18 which plan to be integrated into Nevada 65, the GNOME
> community has decided to bless enchant
> (http://www.abisource.com/projects/enchant/)
> as external dependency (http://live.gnome.org/TwoPointSeventeen/
> ExternalDependencies). GEdit has changed to use enchant instead if
> aspell. The
> enchant website also provide a patch to enable Evolution to use it,
> too. So
> this is a great opportunity to unify our spell checking support on
> JDS.
>
> 3.6. How will you know when you are done?:
> The dictionaries are moved to the new place and the Thunderbird's
> spell
> checker works fine with the symbol links.
>
>4. Technical Description:
> 4.1. Details:
> (It has been confirmed with JDS team that the implementation will have
> nothing to
> do with the C/C++ APIs. It only involes changes to dictionaries'
> place.)
>
> The examples of gnome modules in JDS that need spell check functions
> are Evolution's composer and gedit. Project Enchant will be the
> interface
> between these applications and the dictionaries. Enchant appears to be
> a
> generic spell checking library on the surface. You can request
> dictionaries
> from it, ask if a word is correctly spelled, get corrections for a
> misspelled
> word, etc...
>
> G11n has already shipped the myspell dictionaries in nevada. To
> accommodate Enchant,
> we need to change them to a common directory.
>
> Currently dictionaries are downloaded from
> http://wiki.services.openoffice.org/wiki/Dictionaries
> (the dictionaries are mostly based on GPL/LGPL), and put to
> /usr/lib/thunderbird/dictionaries/ (for Thunderbird2.0). Those
> dictionary files
> will be moved to /usr/share/spell/myspell. Enchant will directly open
> those
> dictionary files under that directory. Meanwhile, because the original
> dictionary
> name is like en_US.dict, which is not recogized by Mozilla that only
> works fine
> with format like en-US.dict, and GNOME components cannot use
> en-US.dict. So the
> solution is to put the original dictionary files to
> /usr/share/spell/myspell,
> and Mozilla(Firefox and Thunderbird) will create symbol links by
> changing "_"
> to "-".
>
> The dictionaries will be delivered as a separate packages so that
> users can
> use it even they don't install Firefox and Thunderbird. There will be
> one package
> for each of the languages supported by our Big Rules plus Englsih and
> one
> combinded package for all other languages.
>
> 4.2. Bug/RFE Number(s):
> 6541402, 6218511
>
> 4.3. In Scope:
> Repackage the existing dictionaries, and add symbol links in JDS
> packages.
>
> 4.4. Out of Scope:
> N/A
>
> 4.5. Interfaces:
>
> Exported Interface:
>
> Interface Name Classification Comment
> ------------------- --------------- --------------
> SUNWmyspell-dictionary-[lang] Uncommitted Dictionaries
> for big-rule lanuages plus
> English.
> [lang] will be a language name.
> SUNWmyspell-dictionary-extra Uncommitted Dictionaries
> for other lanuages
> /usr/share/spell/myspell Volatile The directory
> to hold dictionaries
> /usr/lib/thunderbird/dictionaries/*-* Volatile Symbol link
> to /usr/share/spell/myspell/*_*
>
> 4.6. Doc Impact:
> None.
>
> 4.7. Admin/Config Impact:
> None.
>
> 4.8. HA Impact:
> None.
>
> 4.9. I18N/L10N Impact:
> Yes.
>
> 4.10. Packaging & Delivery:
> Dicitonaries will be packaged and deliverde via
> SUNWmyspell-dictionary-[lang](lang will be en, cs, de, es, fr, hu, it,
> ja, ko,
> pl, pt_BR, ru, sv, zh_CN, zh_HK, zh_TW) and
> SUNWmyspell-dictionary-extra for
> other languages.
>
> The dictionary packages will be delivered togather with GNOME L10N
> packages. While the symbol links will be created by applications that
> need
> spell checking function.
>
> The SUNWmyspell-dictionary-en dictionary will be installed all the
> time
> no mater what locales are selected during installation.
> SUNWmyspell-dictionary-
> extra will be installed when users choose to install anyone of the
> corresponding
> locales. Other SUNWmyspell-dictionary-[lang] packages will be
> installed only
> when users choose to install the locales for language [lang].
>
> 4.11. Security Impact:
> None.
>
> 4.12. Dependencies:
>
> No GNOME applications depends on the C++ interfaces provided by
> enchant. Enchant's myspell backend does not rely on libmyspell.so from
> either
> Thunderbird or Firefox. The fact is Enchant has its own copy of
> myspell code,
> and myspell is build statistically into
> /usr/lib/enchant/libenchant_myspell.
> so (the enchant myspell backend). This is also the way that
> thunderbird and
> firefox uses myspell. Hence, we don't have to worry about whether
> there's any
> C++ related interfaces involvement between enchant and
> thunderbird/firefox.
>
>
>5. Reference Documents:
> [1] Enchant Website: http://www.abisource.com/projects/enchant/
> [2] GNOME 2.18 ARC case: http://sac.eng/Archives/CaseLog/arc/LSARC/2007/146/
>
>
>6. Resources and Schedule:
> 6.1. Projected Availability:
> This project is targeting vermillion_65, which will be integrated into
> snv_65. The test schedule is from 05/08/07 to 05/18/07.
>
> 6.2. Cost of Effort:
> Localization: 1 Human * 0.5 Day
> Testing: 2 Human * 1 Day
>
> 6.3. Cost of Capital Resources:
> None.
>
> 6.4. Product Approval Committee requested information:
> 6.4.1. Consolidation or Component Name: G11n
> 6.4.3. Type of CPT Review and Approval expected: FastTrack
> 6.4.4. Project Boundary Conditions: None
> 6.4.5. Is this a necessary project for OEM agreements: No.
> 6.4.6. Notes: None.
> 6.4.7. Target RTI Date/Release:
> vermillion_65(05/07/07)
> 6.4.8. Target Code Design Review Date: No code
> changes.
> 6.4.9. Update approval addition: None.
>
> 6.5. ARC review type:
> FastTrack
>
>
>7. Prototype Availability:
> 7.1. Prototype Availability:
> No.
>
> 7.2. Prototype Cost:
> None.
>