Description of problem: libreoffice-langpack-LL requires font(:lang=LL). If I try to install libreoffice on a system where no package provides font(:lang=LL), urpmi doesn't suggest all the packages that provides font(:lang=LL). eg. urpmi libreoffice-writer In order to satisfy the 'libreoffice-langpack[== 4.0.0.1-7.mga3]' dependency, one of the following packages is needed: 1- libreoffice-langpack-fr-4.0.0.1-7.mga3.i586: French language pack for LibreOffice (to install) 2- libreoffice-langpack-en-4.0.0.1-7.mga3.i586: English language pack for LibreOffice (to install) 3- libreoffice-langpack-nso-4.0.0.1-7.mga3.i586: Northern Sotho language pack for LibreOffice (to install) 4- libreoffice-langpack-pt-BR-4.0.0.1-7.mga3.i586: Brazilian Portuguese language pack for LibreOffice (to install) What is your choice? (1-4) 1 In order to satisfy the 'font(:lang=fr)' dependency, one of the following packages is needed: 1- sdlbrt-2007.07.14-4.mga3.i586: sdlBasic runtime interpreter (to install) 2- denemo-0.9.6-3.mga3.i586: WYSIWYG musical score editor and frontend for Lilypond (to install) What is your choice? (1-2) only sdlbrt and denemo are suggested in the alternative to satisfy the 'font(:lang=fr)' dependency, while lots of others packages provides 'font(:lang=fr)' (cf. list in attachment). Same problem if I try to install another language langpack. Version-Release number of selected component (if applicable): urpmi-7.15.1-3.mga3 libreoffice-4.0.0.1-7.mga3
CC: (none) => thierry.vignaud
seen that too in the installer https://bugs.mageia.org/show_bug.cgi?id=8808
Created attachment 3437 [details] list of packages that provides 'font(:lang=fr)' rpm -qp --qf='[%{NAME} %{PROVIDES}\n]' *.rpm |grep "font(:lang=fr)"
Priority: Normal => HighAssignee: bugsquad => thierry.vignaud
See also bug 9314 This would possibly explain both these other bugs.
As usual, this is because URPM favors packages with same arch first. Here's the bug is that arched packages provides 'font(XX)' And indeed why the fsck is eg: sdlbrt packaging a font that is already packaged elsewhere instead of just requiring it? Meaning possibly shiping an older version of it. Same for denemo. In fact, the output of "urpmf DejaVuSans.ttf|less" is horrific... Only fonts-ttf-dejavu should package it...
Source RPM: urpmi-7.15.1-3.mga3.src.rpm => denemo, sdlbrt
(In reply to Thierry Vignaud from comment #4) > As usual, this is because URPM favors packages with same arch first. > > Here's the bug is that arched packages provides 'font(XX)' Thanks for the explanation of the behaviour. As a workaround before a better fix of these packages, I pushed updated denemo, fluxbox and sdlbrt with _provides_exceptions so that they don't provide font(:lang=*).
Status: NEW => RESOLVEDResolution: (none) => FIXEDSource RPM: denemo, sdlbrt => denemo, fluxbox, sdlbrt
Summary: urpmi doesnt work correctly with font(:lang=LL) dependencies => some arched packages wrongly provides font(:lang=LL) dependencies (making urpmi not listing noarch ones when asked for a choice)
Blocks: (none) => 9354
All these packages should be fixed to require fonts-ttf-dejavu instead of packaging DejaVu*ttf: 0ad-data briquolo gambas3-gb-sdl libcegui-devel otrs php-jpgraph ruby-prawn-core salasaga sarg sdlbrt stellarium teeworlds-data texlive-texmf ultrastardx wesnoth-data xmoto zabbix-web
Status: RESOLVED => REOPENEDCC: (none) => sander.lepikResolution: FIXED => (none)
CC: (none) => luigiwalser
Fixed: xmoto zabbix-web
CC: (none) => zen25000
It seems wrong just to delete the files... replacing them with symlinks and adding a require seems OK, but as the code in question may use their own hard-coded paths to the font, it's not just as simple as rm'ing and requiring. Also I'm not really sure I see any of the above packages actually providing font(XXX)... am I missing something?
CC: (none) => mageia
rpm -qp --provides /home/linux/mageia/distrib/cauldron/i586/media/core/release/sarg-2.3.2-2.mga3.i586.rpm sarg = 2.3.2-2.mga3 sarg(x86-32) = 2.3.2-2.mga3 sarg isn't providing a font(XXX).
I checked a few of them and none I could see were providing this so I think the analysis isn't quite right...
As you can see above, some were and were "fixed" in as "let's blacklist those provides". I do think packages should not duplicate fonts. They don't benefit from font fixes and they waste space.
For example, yofrankie-bge still provides 'fonts*'
Oh, don't get me wrong, I agree that there is no need to duplicate the fonts. All I'm saying is that it's not just a simple matter of rm'ing the files in the %install. You have to do: Check the code to see if it loads the font files generically or from a fixed path. A. If generic, then just rm the file and add a Requires for the relevant font pkg. B. If specific path, then 1. rm the file and replace it with a symlink to the font or 2. Patch the code to load it from generic location. If you pick 1, then there is the risk of breakage if the file is ever renamed in the original package and the symlink becomes broken. It may also throw up a broken symlink RPM lint error, so the symlink might actually have to be %ghosted and then created in %post instead. So all in all it's non-trivial to drop the fonts from any given package. Also in the case of the yofrankie-bge, it actually does ship it's fonts in the standard location: $ urpmq -l yofrankie-bge| grep ttf /usr/share/fonts/truetype/yo_frankie.ttf /usr/share/yofrankie-bge/menus/yo_frankie.ttf So is this actually an error?
Is this bug (still) valid?
Keywords: (none) => NEEDINFO
We don't have arched packages providing 'font(...' but we still have binary packages providing DejaVu fonts: briquolo-0.5.7-8.mga4.x86_64.rpm clanbomber-2.1.1-9.mga4.x86_64.rpm enigma-1.20-2.mga4.x86_64.rpm gambas3-gb-sdl-3.4.2-2.mga4.x86_64.rpm gambas3-gb-sdl-sound-3.4.2-2.mga4.x86_64.rpm lib64cegui-devel-0.7.7-5.mga4.x86_64.rpm ls: cannot access libcegui-devel*: No such file or directory mygui-3.2.0-4.mga4.x86_64.rpm mygui-demos-3.2.0-4.mga4.x86_64.rpm mygui-docs-3.2.0-4.mga4.x86_64.rpm mygui-tools-3.2.0-4.mga4.x86_64.rpm neverball-1.5.4-7.mga4.x86_64.rpm openmw-0.25.0-1.mga4.x86_64.rpm pnp4nagios-0.6.21-1.mga4.x86_64.rpm pokerth-1.0-5.mga4.x86_64.rpm pokerth-server-1.0-5.mga4.x86_64.rpm salasaga-0.8.0-4.mga3.x86_64.rpm sarg-2.3.2-2.mga3.x86_64.rpm scilab-5.4.0-2.mga4.x86_64.rpm scilab-devel-5.4.0-2.mga4.x86_64.rpm stellarium-0.12.2-1.mga4.x86_64.rpm teeworlds-data-0.6.1-5.mga3.x86_64.rpm xbmc-12.2-2.mga4.x86_64.rpm xbmc-addon-xvdr-0.9.5-0.git20120307.2.mga3.x86_64.rpm xbmc-eventclient-j2me-12.2-2.mga4.x86_64.rpm xbmc-eventclient-ps3-12.2-2.mga4.x86_64.rpm xbmc-eventclients-common-12.2-2.mga4.x86_64.rpm xbmc-eventclients-devel-12.2-2.mga4.x86_64.rpm xbmc-eventclient-wiiremote-12.2-2.mga4.x86_64.rpm xbmc-eventclient-xbmc-send-12.2-2.mga4.x86_64.rpm xmoto-0.5.10-5.mga4.x86_64.rpm zabbix-web-2.0.5-1.mga3.x86_64.rpm
Thanks Thierry. In most cases, I'd think it'd be safe to just delete them from those packages.
Keywords: NEEDINFO => (none)
I already fixed: briquolo xmoto zabbix-web - so not sure how that list above was generated.
Sure: $ rpm -qpl xmoto-0.5.10-6.mga4.x86_64.rpm |grep ttf /usr/share/games/xmoto/Textures/Fonts/DejaVuSans.ttf /usr/share/games/xmoto/Textures/Fonts/DejaVuSansMono.ttf $ rpm -qpl -0.5.7-8.mga4.x86_64.rpm |grep ttf /usr/share/doc/briquolo/DejaVuSans.ttf-LICENSE /usr/share/games/briquolo/data/DejaVuSans.ttf (...)
Yes, they are symlinks to the DejaVu packaged files: [baz@jackodesktop ~]$ cd /usr/share/games/xmoto/Textures/Fonts [baz@jackodesktop Fonts]$ ll Deja* lrwxrwxrwx 1 root root 63 Sep 2 00:09 DejaVuSansMono.ttf -> ../../../../../../usr/share/fonts/TTF/dejavu/DejaVuSansMono.ttf lrwxrwxrwx 1 root root 59 Sep 2 00:09 DejaVuSans.ttf -> ../../../../../../usr/share/fonts/TTF/dejavu/DejaVuSans.ttf [baz@jackodesktop ~]$ cd /usr/share/games/briquolo/data [baz@jackodesktop data]$ ll DejaVuSans.ttf lrwxrwxrwx 1 root root 56 Sep 13 13:08 DejaVuSans.ttf -> ../../../../../usr/share/fonts/TTF/dejavu/DejaVuSans.ttf I have removed the DejaVu license from briquolo
Fixed in teeworlds-data (that I also switched to noarch). I used the symlink method, but as Colin pointed out, that may not be the best one.
CC: (none) => remi
Have all packages been fixed? If not, what's the list of the packages to be fixed?
Assignee: thierry.vignaud => pkg-bugs
Target Milestone: --- => Mageia 6
Status comment: (none) => Many packages fixed, no news since 2 years, need to update the list or close the bug report.
no news since 6 monthes. Please reopen if still valid
Status: REOPENED => RESOLVEDCC: (none) => mageiaResolution: (none) => FIXED