Re: Selection of dictionaries per installation

Stephan Bergmann píše v Po 10. 09. 2012 v 17:53 +0200:
> On 09/10/2012 05:09 PM, Andras Timar wrote:
> > 2012/9/10 Stephan Bergmann <sbergman@redhat.com>:
> > > On 08/30/2012 01:16 PM, Stephan Bergmann wrote:
> > > > PS1: The way dictionaries "related" to a given locale are determined
> > > > appears to be the the list at
> > > > setup_native/source/packinfo/spellchecker_selection.txt.  That's why the
> > > > en-US base installation set for Linux and Mac OS X contains dict-en,
> > > > dict-es, and dict-fr, for example.  However, an apparent inconsistency
> > > > is that langpack_de only contains dict-de, and not also dict-fr and
> > > > dict-it, as that list would suggest.
> > >
> > > Looks like that spellchecker_selection.txt (aka SPELLCHECKERFILE,
> > > instsetoo_native/util/openoffice.lst) is only consulted when creating "base"
> > > installation sets, not when creating langpacks (whether or not that's by
> > > design or by mistake).
> >
> > I think it is by design. It would not be good, when different
> > langpacks wanted to install the same dictionary. Package conflict
> > would occur.
>
> But wouldn't there already be a conflict between the "base" (en-US) 
> installation set providing dict-fr and the fr langpack providing dict-fr 
> too, then?
>
> I think there's no package conflict involved here, anyway, as the 
> various installation sets ("base," langpacks) are simply collections of 
> (rpm etc.) packages, and no problem should arise if a single package is 
> contained in multiple such collections.

I see only two problems :-)

1. It duplicates the files and take space on mirrors. IMHO, it would be
acceptable if it does not double the size of each langpack.

2. It cause troubles if people install the packages the following way:

      + tar -xz LibO_*_langpack-*.tar.gz
      + cd LibO_*_langpack-*/RPMS
      + rpm -Uvh *.rpm

   It would complain the the libreoffice3.6-dict-<lang> package is
   already installed in the system from other lang pack.

   A solution would be to use the same top-level directory in all
   tarballs, so all rpms are uncompressed into the same RPMS subdir.
   It will need some detective work in the perl installer. The problem
   might be that it allows to create more tarballs in parallel, so
   the non-conflicting top-level directory is helpful. Though, this
   should be solvable another way.
   
Best Regards,
Petr