Subject: [bug#71659] [PATCH] gnu: Add fastfetch.

From: Dariqq <[email-masked]>
Date: Fri, 21 Jun 2024 10:56:41 +0000

Hi Richard,

I have just reported the LM detection issue upstream. So hopefully it 
will be fixed soon and we can ignore it in the guix package.

On 20.06.24 20:34, Richard Sent wrote:

> 
> I agree, I think this package would benefit from a -minimal version or
> some similar structure with variants.
> 

A minimal version sounds like a great idea and would be easy to 
customize by just adding the relevant packages.

The question then becomes which features to include in a minimal build. 
Afaik apart from hwdata and libdrm  (for specifying the custom paths) 
none are really required.

The upstream wiki has some infos what is used for what. Apart from 
libdrm is there anything is there a feature you'd think that should be 
included in a -minimal version?

>> network-manager
> 
> I wonder if adding the network-manager plugin can cause issues on
> systems that don't use it. (e.g. connman). I'd be a little worried
> they'd start fighting.
> 
Great catch.
I havent even thought about this being an issue as i have only ever been 
using  %desktop-services.

It feels like there are a lot of things that have (explicit or implicit) 
assumptions on the system being used.

- LM : logind
- Music: dbus
- Wifi: networkmanager
- maybe more.

>>> Is there anything I can help with?
>>
>> I have built with "-DBINARY_LINK_TYPE=dynamic" to dynamically link the
>> dependencies instead. There was an error due to fastfetch wanting a
>> newer version of ddcutil. Havent looked into how complicated that is to
>> update yet.
>>
>> On a related note dynamically linking would avoid the (kind of awkward)
>> wrapper. Are there benefits/downsides to using that instead?
> 
> I'm no expert but dynamic linking sounds like a better solution to me
> than a wrapper + dlopen. Disabling runtime linking seems to be a
> semi-common thing in packages. Maybe we'll get lucky and ddcutil can be
> updated without any breakages.
> 
>> I hope the formating turned out ok for the code blocks
> 
> Looks great.
> 

Slightly related: What do you think of the current guix package 
detection? As it is not really comparable to package count in other 
distributions.

My first implementation (in 2.14.0) is just counting lines in the output 
of "guix package -I" which only counts packages explicitly installed.

As that was kind of slow I rewrote it (as of 2.15) to count unique 
/gnu/store/* entries in the profile manifest files (e.g. 
/run/current-system/profile/manifest) directly with C which also counts 
propagated inputs and ignores the lisy syntax of the file.

The nix package detection parses the (nix equivalent) of "guix gc -R 
$(realpath PROFILE)" which gives counts similiar to other systems but 
was even slower and I haven't thought about a good way to filter out 
packages from the list (as there are also things like the computed 
info-dir , etc in there)

The nix implementation sidesteps the slowness problem by caching results.

I thought about using libguile directly but this is above my C and guile 
knowledge.

Have a nice day,
Dariqq