GNU bug report logs -
#50358
[PATCH core-updates-frozen 0/8] Shortened Rust bootstrap & other fixes.
Previous Next
Full log
View this message in rfc822 format
Hello,
Ludovic Courtès <ludo <at> gnu.org> writes:
> Hi,
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>> I feel like search-path-specification should be augmented to express
>> patterns that would be useful with search paths such as the too wide
>> XDG_DATA_DIRS: enable only when a child directory/file is present, for
>> example.
>>
>> So far we've been adding ad-hoc fixes in build systems (such as for the
>> qt-build-system, via (guix build qt-utils)); it seems it'd be cleaner to
>> add this capability at the search path level.
>>
>> What do you think?
>
> I’m of the kind who’d rather have reality match the model. ;-)
Haha! Tough!
> I think it would be nice to have a FONTCONFIG_FONT_PATH variable that
> would only look at share/fonts.
That'd be nice, but probably harder to convince them than for
XDG_DATA_DIRS, as we'd probably be the only user.
> What you describe would have uses beyond fontconfig, which is nice. The
> downside is that it would make search path semantics and their
> implementation more complex; we’d have to see what the impact is.
Yes, more complexity, but localized (and can be tested), rather than
diffused (and untested) as of now.
> Thinking about it, I wonder if having (file-pattern "^fonts$") would
> work here. But then, what if a profile contains several packages with
> an XDG_DATA_DIRS search path but different ‘file-pattern’ values?…
Perhaps this could work too, *if* the behavior of various same-named
environment variable specifications is to be combined into a logical OR
manner (I haven't checked what the current behavior is, but I seem to
recall it not working from past experiments).
Thanks,
Maxim
This bug report was last modified 3 years and 189 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.