Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 97401 - acroread 7 ebuild language code not too clever
Summary: acroread 7 ebuild language code not too clever
Status: RESOLVED CANTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Printing Team
URL:
Whiteboard:
Keywords:
: 107937 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-06-29 09:25 UTC by Simon Blanchard
Modified: 2005-10-02 23:08 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Blanchard 2005-06-29 09:25:39 UTC
The code in the acroread 7 ebuild file that tries to find out which language the user wants to install is 
not too clever. It runs along a list and breaks when it finds a match in the linguas in the make.conf 
What if your default language is not first in the list or in the list at all. For example, my default is 
English but my linguas list Japanese, Chinese and Korean in that order. So I ended up with Japanese 
acroread. There should be a clearer way of specifying the desired language.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2005-06-29 09:35:32 UTC
Stefan, could you look at Bug 92699, comment #16 if it's a viable solution?
Comment 2 Stefan Schweizer (RETIRED) gentoo-dev 2005-06-29 09:50:37 UTC
does the japanese acroread not include the english text and you can switch on
startup?

For the german version this is possible.
Comment 3 Fred Labrosse 2005-06-30 03:18:15 UTC
My LINGUAS is: 
 
LINGUAS="en_GB fr" 
 
and I only get the French version.  And no I can't switch to English. 
Comment 4 Mark Purtill 2005-07-02 11:00:18 UTC
I ran into this too.  acroread-asianfonts told me to add "ja" to my LINGUAS to
get the Japanese fonts (so I changed it to LINGUAS="en ja"), which then causes
acroread to install the Japanese version.  As I'm just a student of Japanese, I
can't tell if there's any way to turn on English test---the GUI is all in
Japanese.  I suspect this is a not-uncommon situation, so even if there is a way
to switch to english, the current scheme isn't acceptable.

BTW, portage also gets confused by acroread-7 being stable but
acroread-asianfonts-7 being unstable.  It keeps threatening to downgrade to
acroread-5 (though it never seems to actually do it).
Comment 5 Kevin F. Quinn (RETIRED) gentoo-dev 2005-07-11 15:51:18 UTC
To add a note of confirmation; I just installed and it came up in German, only.
 The choice to select languages only offers German.  My LINGUAS is set to:

LINGUAS="en_GB it de es fr"

'de' being the first SRC_URI that matched.  THe problem doesn't go away by
adding a 'linguas_en?...' line at the start - people who have, for example, "fr
en" would end up with English when they obviously want French if only one can be
installed.

The natural interpretation of LINGUAS is that support for all languages
specified should be included if possible (in which case, 'strip-linguas' from
the eutils eclass is probably a good idea).  However, if that's not possible
then the natural expectation is that the first supported language from LINGUAS
will be installed.  I'm not sure that's trivial however, whilst obeying the
rules about variables like SRC_URI; but there may some ideas worth stealing from
the kde-meta ebuild & kde-functions.eclass.
Comment 6 Mark Purtill 2005-07-11 20:10:51 UTC
In view of GLSA 200507-09 (Adobe Acrobat Reader: Buffer overflow vulnerability),
this has moved from minor annoyance to major problem.  According to that
advisory, I need to upgrade to Acrobat 7, but with the current emerge, the only
way I can do that is (and not get a Japanese version) is to unset LINGUAS
entirely, which will mess up other ebuilds.  So could we get a fix for this
(even if not a perfect one) quickly?
Comment 7 Kevin F. Quinn (RETIRED) gentoo-dev 2005-07-12 08:30:00 UTC
Mark, the easiest way to get it installed in English is to do:

LINGUAS="en" emerge acroread

which will get you up to v7 with the US English version (change 'en' to the
language you want, chosen from the supported list; de, fr, ja, ko, zh_CN,
zh_TW).  You don't need to change the LINGUAS variable in make.conf, the one
specified on the command line above overrides.  That way any other emerges you
do later won't be affected.

If 'emerge -pv acroread' shows it will update other packages first, emerge them
first as normal before doing the above trick just for acroread.
Comment 8 Kevin F. Quinn (RETIRED) gentoo-dev 2005-07-12 09:45:03 UTC
I've had a play around and I think there's no way to get things working
satisfactorily with SRC_URI and LINGUAS as they stand today, ensuring that (1)
digests are built properly (2) users only download the selected language file
and (3) the user gets the language they expect.

Unless someone comes up with a cunning trick to satisfy 1, 2, and 3, I'd suggest
the easiest way to make the ebuild sane is to define local use flags for each
language acroread supports and avoid LINGUAS completely (i.e. replace 'linguas_'
with 'acroread_', add to IUSE, and to use.desc.local - where a comment that only
one acroread_<lang> should be specified by the user would be sensible).
Comment 9 Pedro Palhoto 2005-08-17 15:48:20 UTC
For the acroread ebuild maintainer(s),        
       
A simple correction for systems with English upfront in the LINGUAS        
variable (with other languages present), is done just by changing the beginning      
of the SRC_URI to:        
        
SRC_URI="linguas_en? ( ${SRC_HEAD}/enu/AdobeReader_enu${SRC_FOOT} )       
        !linguas_en? ( linguas_de? ( ${SRC_HEAD}/deu/AdobeReader_deu${SRC_FOOT}       
)      
[...]"     
     
Unfortunatly this does not resolve the order problem, it selects the first in    
the ebuild order that is present in the entire LINGUAS string; if you have   
LINGUAS="fr de", for example, the German version is selected.  
      
There are also other ebuilds, such as nwn, that don't have the conditional      
"en". Just wondering if the Gentoo Developer Docs have a passage concerning the      
i18n aspects of ebuild programming. 
 
Is there a linguas "get" command given the index, i.e., for iteration use? 
Comment 10 Nils Marving 2005-09-17 13:04:58 UTC
This seems to be unfixed, is it assigned to the correct team?
Comment 11 Stefan Schweizer (RETIRED) gentoo-dev 2005-09-17 14:15:07 UTC
This cannot be fixed due to Acrobat not allowing multiple languages on the same
system.

Portage cannot detect only the first language in linguas, so we have to take one
of them based on a random list, sorry.
Comment 12 Mark Purtill 2005-09-17 14:23:47 UTC
As noted in Bug 92699, comment #16 (referenced in comment #1 above), openoffice
manages to detect only the first language in linguas with no problem.  So
CANTFIX is not correct.  If no one wants to fix this, mark it WONTFIX.
Comment 13 Stefan Schweizer (RETIRED) gentoo-dev 2005-09-17 14:34:18 UTC
ok, here for you again: 
Adobe does not provide one big package and small language extensions
Openoffice does. We cannot go the way of uselessly downloading and installing
everything as openoffice-bin does because adobe provides only big packages and
does not give a way to install multiple languages.
Because portage cannot detect the first language-code in linguas we cannot fix this.
And please talk to me in IRC if you still have problems with understanding why
it does not work instead of spamming this bug.

Oh, and sure I want to fix it. I would have already done it, if I had a solution.
Comment 14 Jakub Moc (RETIRED) gentoo-dev 2005-10-02 23:08:50 UTC
*** Bug 107937 has been marked as a duplicate of this bug. ***