[Bug] Linglong detection fails on Debian 13 for installations from Deepin's repository

[GuilingQiyu]

Bug Description

Fastfetch does not detect Linglong packages on a Debian 13 "Trixie" system when Linglong is installed from a third-party repository provided by the Deepin team. This issue persists even with the latest Fastfetch version (2.50.0).

To Reproduce

1. Start with a clean Debian 13 "Trixie" system.
2. Add the Deepin Linglong repository using the following command:

   echo "deb [trusted=yes] [https://ci.deepin.com/repo/obs/linglong:/CI:/release/Debian_13/](https://ci.deepin.com/repo/obs/linglong:/CI:/release/Debian_13/) ./" | sudo tee /etc/apt/sources.list.d/linglong.list

3. Update the package list and install the Linglong components:

   sudo apt update
   sudo apt install linglong-bin linglong-box linglong-builder

4. Install at least one Linglong application, for example, WeChat:

   ll-cli install com.tencent.wechat

5. Install or update to the latest version of Fastfetch. In my case, I upgraded from the Debian repo version (2.40.4) to the latest release from GitHub (2.50.0).

   glqyu@GLQY-Debian:~$ fastfetch --version
   fastfetch 2.50.0 (x86_64)
   

6. Run fastfetch.

Expected Behavior

The Packages: line in the fastfetch output should include a count for Linglong, for example:
Packages: 3369 (dpkg), 11 (flatpak), 2 (linglong)

Actual Behavior

The Linglong count is completely missing from the output.

System Information (output from fastfetch)

OS: Debian GNU/Linux 13 (trixie) x86\_64
Host: ASUS TUF Gaming A15 FA506QM\_FA506QM (1.0)
Kernel: Linux 6.12.38+deb13-amd64
Uptime: 1 hour, 8 mins
Packages: 3369 (dpkg), 11 (flatpak)
Shell: bash 5.2.37
DE: KDE Plasma 6.3.6
WM: KWin (Wayland)
... (and other system details)

Investigation and Findings

I have confirmed that the detection is failing because this Linglong installation uses a different path than the one Fastfetch currently checks.

First, I listed my installed Linglong packages, confirming two are present:

$ ll-cli list
ID                      Name                    Version         Channel         Arch            Description
com.tencent.wechat      WeChat(Test Version)    4.0.1.13        main            binary          The Tencent WeChat Linux official version
org.deepin.base         deepin-base             25.2.0.92       main            binary          deepin base environment.

Then, I directly checked the path that the Fastfetch source code uses for detection (/var/lib/linglong/repo/refs/heads/main) and confirmed it is empty on my system, while the remotes directory exists alongside it:

$ ls /var/lib/linglong/repo/refs/heads/main
ls: cannot access '/var/lib/linglong/repo/refs/heads/main': No such file or directory

$ ls /var/lib/linglong/repo/refs
heads   mirrors   remotes

Finally, I used find to locate the package files, which confirms they are under the remotes/stable/main subdirectory:

$ sudo find / -name "*org.deepin.base*"
find: ‘/run/user/1000/doc’: Permission denied
/var/lib/linglong/repo/refs/remotes/stable/main/org.deepin.base
/var/lib/linglong/layers/0286c7ff50b7246d0583675a5c9fbf2fa601373f5f34439dec05b5f70ab145ea/org.deepin.base.install

This demonstrates that the Linglong applications and their metadata are located under the .../repo/refs/remotes/stable/main path, not the .../repo/refs/heads/main path that Fastfetch's logic currently relies on. The detection logic needs to be updated to check this alternative path as well.

Thank you for creating such a great tool!

[CarterLi]

Checked it my self in a Deepin live CD. It's /ci/main, instead of stable/main

[CarterLi]

Should we enumerate all sub-paths in /var/lib/linglong/repo/refs/remotes? What's the differenct of these paths?

[GuilingQiyu]

Should we enumerate all sub-paths in /var/lib/linglong/repo/refs/remotes? What's the differenct of these paths?

Thank you for looking into this. Following up on your question about the different paths, I've done some investigation on a native Deepin system and I think that I have an answer.

Based on my observations, the directory structure appears to be as follows:

/var/lib/linglong/repo/refs/remotes/ci/main : This directory seems to contain the system-integrated Linglong packages. These are the base applications that come with Deepin OS and are likely managed and updated along with system updates.

/var/lib/linglong/repo/refs/remotes/stable/main : This directory appears to hold packages that have been installed or updated by the user through the Linglong App Store. I can recognize the applications in this path as the ones I have personally managed. It seems that packages in stable take priority over or override the versions in ci.

Therefore, to get a complete and accurate count of all user-facing Linglong packages, the correct approach might be to sum the counts from both directories (ci/main and stable/main).

[GuilingQiyu]

Should we enumerate all sub-paths in /var/lib/linglong/repo/refs/remotes? What's the differenct of these paths?

I have a significant new finding that the directories under /var/lib/linglong/repo are merely repository references, and counting them is incorrect as it does not reflect the actual number of installed packages.

The actual installed package data resides in hash-named subdirectories under:
/var/lib/linglong/layers

Each subdirectory here represents an installed "layer" (which can be an app, a runtime, etc.). On my Deepin system, the number of directories here is 19, which I can confirm is the correct number of total Linglong packages installed. On my Debian system, there are 2 directories, matching the 2 apps I installed.

Therefore the most accurate and robust method might be to simply count the number of subdirectories inside /var/lib/linglong/layers.

Each subdirectory in this path represents a fully installed package "layer" (be it an app, a runtime, or a base).

$ ls /var/lib/linglong/layers/9440d287e83833ee447c49ee49cd6ef60913f88e3421c6030cfd9f5b2f5cc6d8
entries  files  info.json  linglong.yaml  org.deepin.mail.install

And cat info.json:

{
  "arch": ["x86_64"],
  "base": "main:org.deepin.base/25.2.0/x86_64",
  "channel": "main",
  "command": ["deepin-mail"],
  "description": "Mail for DDE.\n",
  "id": "org.deepin.mail",
  "kind": "app",
  "module": "binary",
  "name": "deepin-mail",
  "runtime": "main:org.deepin.runtime.webengine/25.2.0/x86_64",
  "schema_version": "1.0",
  "size": 79117428,
  "version": "6.5.35.1"
}

A base example is here:

{
  "schema_version": "1.0",
  "id": "org.deepin.base",
  "arch": [
    "x86_64"
  ],
  "base": "org.deepin.empty/20.0.0",
  "description": "deepin base environment.\n",
  "kind": "base",
  "module": "binary",
  "name": "deepin-base",
  "overlayfs": {},
  "permissions": {},
  "runtime": "latest",
  "size": 10485760,
  "version": "25.2.0.92",
  "channel": "main",
  "extensions": [
    {
      "name": "org.deepin.driver.display.nvidia",
      "version": "1.0.0",
      "directory": "opt/extensions/org.deepin.driver.display.nvidia",
      "allow_env": {
        "__EGL_VENDOR_LIBRARY_DIRS": "/usr/share/glvnd/egl_vendor.d",
        "__EGL_EXTERNAL_PLATFORM_CONFIG_DIRS": "",
        "VK_ADD_DRIVER_FILES": ""
      }
    },
    {
      "name": "com.glenfly.driver.display.arise",
      "version": "1.0.0",
      "directory": "opt/extensions/com.glenfly.driver.display.arise",
      "allow_env": {
        "__EGL_VENDOR_LIBRARY_DIRS": "/usr/share/glvnd/egl_vendor.d",
        "LIBGL_DRIVERS_PATH": "/usr/lib/x86_64-linux-gnu/dri",
        "GBM_BACKENDS_PATH": "/usr/lib/x86_64-linux-gnu/gbm"
      }
    },
    {
      "name": "org.deepin.driver.media.intel",
      "version": "25.0.0",
      "directory": "opt/extensions/org.deepin.driver.media.intel",
      "allow_env": {
        "LIBVA_DRIVERS_PATH": "/usr/lib/x86_64-linux-gnu/dri"
      }
    }
  ]
}