file dependencies and packages and [blocker] bugs

Hans de Goede j.w.r.degoede at hhs.nl
Mon Mar 3 21:16:19 UTC 2008


Andrew Farris wrote:
> Hans de Goede wrote:
>> Bill Nottingham wrote:
>>> Hans de Goede (j.w.r.degoede at hhs.nl) said:
>>>>> So, maybe I'm insane, but if all you want is a sans bold, etc. font 
>>>>> - that
>>>>> can't be more than about 20 lines of fontconfig code to look for a 
>>>>> match
>>>>> for the 'sans' pattern and get a filename. That way:
>>>>>
>>>>> - you don't have to hardcode any files
>>>>> - you don't have to hardcode any requirements
>>>>>
>>>>
>>>> Erm, yes and our mantra is upstream, and most of these apps are 
>>>> portable (using SDL + SDL_ttf for example), how am I going to get 
>>>> this upstream, last I checked there was no fontconfig under windows, 
>>>> let alone on devices like the gp2x.
>>>>
>>>> Really this is not a problem of the apps, people should stop 
>>>> thinking about this as being a problem of the apps, there are just 
>>>> too many apps doing this, this should be fixed centrally.
>>>
>>> Let me try to understand:
>>>
>>> You would rather:
>>> - add 2000 more file entries to the metadata for everyone to download 
>>> on every
>>>   update
>>> - manually track when files move and update all your packages
>>>
>>> than:
>>> - add and carry a ~20 line patch that absolves you from having to fix 
>>> your
>>>   packages when they change?
>>>
>>
>> <sigh> (getting somwwhat tired of discussion.
>>
>> Basicly: yes
>> Because:
>> -adding a Requires: /usr/share/fonts/foo/bar.ttf line to my package is 
>> trivial
>> -font renames are rare
>> -even if font renames happen fixes is easy
>> -games were designed with a certain look and feel, depending on 
>> getting that
>>  exacy font, fontconfig is somewhat fuzzy with which font you'll get
> 
> I would like to point out again, that because games are designed for a 
> specific metric to fit within a surface in a pixel size the game 
> developer chose to fit within theme of the game scene... the package 
> should be carrying the font as game data.
> 
> The rest of the Fedora world should not care about that game carrying a 
> minor portion of data specifically chosen to work well with that game's 
> rendering engine within its own scenes.  However, the rest of the Fedora 
> world downloading filelists due to some game packages not carrying a 
> small font as game data seems a bit excessive.  The game essentially 
> requires a font file (which it converts to images on a surface) as game 
> data; what rationale is there for it not being game data just because it 
> happens to exist elsewhere on the system in the same format?  The only 
> benefit of that choice is a smaller game data package and smaller 
> installed size for those users who happen to install that game (are they 
> concerned about space while installing games?).
> 
> I know my opinion is just my own, but this seems backwards to me.  If 
> the game is not using system font rendering it should be carrying the 
> font as its own data, just like the sprites and backgrounds it also no 
> doubt has.
> 
> That said, Hans you don't have to respond I know you've already 
> responded ('live with it').  Still, it seems like a solution to 
> significantly reduce bandwidth used by not pulling filelists as often 
> exists and is simple.

Actually keeping the font files as private data sounds like a reasonable 
approach, given how important this appearantly is to people.

I don't find it elegant to carry system font files as private data, because 
fonts get bugfixes too, and some games might benefit from these.

But shipping fonts as private data is what most games currenty actually do, and 
given that they use their own rendering (and usually their own text encoding 
schemes like latin1) this isn't completely strange either.

So if there are no objections I am willing to "fix" the 2 packages currently 
symlink fonts (as replacement for microsoft fonts used by upstream) to just 
include private copies of the currently symlinked fonts instead.

Although not 100% ellegant this will solve the filedep issue at hand, without 
much downsides.

---

Alternative:

Put the files under /usr/share/fonts in the default metadata instead of in the
filelist. I know this are 2000 files, but that only goes for the main repo
metadata which is downloaded only once. The updates metadata should contain 
only files of packages in updates, and although some fonts might get updates, 
the list of files under /usr/share/fonts in updates should never grow really large.

Regards,

Hans




More information about the devel mailing list