gdu

English

Overview

gdu is an upstream command-line disk usage analyzer written in Go. It is intended to help users inspect how disk space is distributed across directories and files from a terminal session. The upstream project describes it as a fast disk usage analyzer with a console interface. (github.com)

Purpose and typical use cases

Typical use cases include:

• locating large directories or files during storage investigation;
• reviewing filesystem usage from an interactive terminal interface;
• generating non-interactive output for scripts or reports;
• inspecting a mounted filesystem or a selected directory tree when manual review is needed. (github.com)

Typical users include:

• system administrators managing local or remote Linux systems;
• developers working with build trees, caches, or workspace directories;
• CI/CD maintainers checking workspace growth or artifact accumulation;
• security engineers reviewing storage usage during incident response or host triage;
• desktop users who need a terminal-based disk usage browser. Some of these user groups are inferred from the tool’s purpose and should be verified by NiceOS maintainers if local packaging expectations differ. (github.com)

Upstream project

The upstream project is hosted at dundee/gdu. The upstream repository includes the main README, installation notes, configuration documentation, and a manual page source. The upstream README states that the project is written in Go and provides command-line and interactive disk usage analysis features. (github.com)

Dist-git repository contents

This NiceOS dist-git repository contains packaging and metadata files, not a full copy of the upstream source tree.

• SPECS/: RPM spec files and related packaging logic.
• SOURCES/: source metadata and manifest files used to track the expected upstream inputs.
• METADATA/: repository metadata used by the packaging workflow.
• SBOM/: software bill of materials material, when present in the package workflow.

Large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through manifest files in SOURCES/. Maintainers should verify the exact manifest format used by this package before making updates. The repository layout is based on the package facts provided for this dist-git repository. (github.com)

Source storage and integrity policy

The packaging workflow for this repository is expected to keep large upstream source archives outside Git. The repository tracks source inputs through manifest metadata in SOURCES/ rather than by storing the archives themselves.

For updates, NiceOS maintainers should verify:

• that the manifest entries in SOURCES/ match the intended upstream source inputs;
• that any required packaging metadata still points to the correct upstream content;
• that no obsolete source references remain after an update;
• that any generated packaging files remain consistent with the spec and source layout.

No concrete hashes are printed in this README. Maintainers should use the repository’s normal source verification workflow when reviewing an update.

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check:

• upstream release notes, changelog, and repository changes for behavior changes that affect the package;
• whether the spec file needs changes for new build flags, renamed files, or changed install paths;
• whether man page sources, configuration documentation, or generated files need regeneration;
• whether packaging scripts still install the correct binary names and auxiliary files;
• whether the update changes runtime behavior relevant to terminal, filesystem, or database-backed modes; this should be verified from upstream documentation rather than assumed. (github.com)

Risks to consider include:

• changes in command-line flags or defaults;
• changes in generated documentation or manual pages;
• changes in build requirements or module layout;
• changes in output format that could affect scripts or automation.

If any of these points are uncertain, NiceOS maintainers should verify them against upstream sources before merging the update.

Build and verification checklist

For RPM maintenance, a typical checklist is:

1. Confirm that the intended upstream source set is reflected in SOURCES/.
2. Review the spec file for patches, file lists, and install sections.
3. Check whether documentation or man page artifacts need regeneration.
4. Build the package in a clean environment.
5. Verify that the built RPM installs the expected binary and documentation files.
6. Run available package tests or upstream tests when practical.
7. Check the resulting binary with basic commands such as help output and a simple directory scan.
8. Review the final RPM for unexpected file ownership, permissions, or dependencies.
9. Ensure the SRPM and binary RPMs are reproducible within the repository’s packaging process where applicable.

References

• Upstream repository (github.com)
• Upstream README (github.com)
• Upstream installation notes (github.com)
• Upstream configuration documentation (github.com)
• Upstream manual page source (github.com)

Русский

Обзор

gdu — это upstream-инструмент командной строки для анализа использования дискового пространства, написанный на Go. Он предназначен для просмотра распределения занятого места по каталогам и файлам из терминальной сессии. В upstream-проекте он описан как быстрый анализатор использования диска с консольным интерфейсом. (github.com)

Назначение и типовые сценарии использования

Типовые сценарии использования:

• поиск крупных каталогов и файлов при анализе заполнения диска;
• просмотр использования файловой системы в интерактивном терминальном интерфейсе;
• получение неинтерактивного вывода для сценариев автоматизации или отчётов;
• изучение смонтированной файловой системы или выбранного дерева каталогов при ручной проверке. (github.com)

Типовые пользователи:

• системные администраторы, работающие с локальными или удалёнными Linux-системами;
• разработчики, анализирующие рабочие каталоги, кэши и деревья сборки;
• сопровождающие CI/CD, контролирующие рост рабочих пространств и накопление артефактов;
• инженеры по безопасности, использующие инструмент при первичной оценке узла или во время разбора инцидента;
• обычные пользователи рабочего стола, которым нужен терминальный просмотрщик использования диска. Часть этих групп выведена из назначения инструмента и должна быть подтверждена сопровождающими NiceOS, если локальные требования к пакету отличаются. (github.com)

Upstream-проект

Upstream-проект размещён в репозитории dundee/gdu. В upstream-репозитории находятся основной README, материалы по установке, документация по конфигурации и исходник страницы manual. В upstream README указано, что проект написан на Go и предоставляет интерактивный и командный анализ использования диска. (github.com)

Содержимое dist-git репозитория

Этот NiceOS dist-git репозиторий содержит упаковочные и метаданные, а не полное зеркало исходного дерева upstream.

• SPECS/: spec-файлы RPM и связанная с упаковкой логика.
• SOURCES/: метаданные и manifest-файлы для контроля ожидаемых upstream-входов.
• METADATA/: метаданные репозитория, используемые в процессе упаковки.
• SBOM/: материалы ведомости состава ПО, если они присутствуют в рабочем процессе пакета.

Крупные архивы upstream-исходников намеренно не хранятся в этом Git-репозитории. Вместо этого контроль целостности исходников ведётся через manifest-файлы в SOURCES/. Сопровождающим следует проверить точный формат manifest-файлов, используемый этим пакетом, перед обновлением. Указание на layout репозитория основано на фактах, предоставленных для этого dist-git репозитория. (github.com)

Политика хранения исходных файлов и контроля целостности

В рабочем процессе этого репозитория ожидается, что большие upstream-архивы не будут храниться в Git. Репозиторий отслеживает исходные входы через manifest-метаданные в SOURCES/, а не за счёт хранения самих архивов.

При обновлении NiceOS-сопровождающим следует проверить:

• что записи в manifest-файлах SOURCES/ соответствуют нужным upstream-исходникам;
• что упаковочные метаданные указывают на правильный upstream-контент;
• что после обновления не остались устаревшие ссылки на исходники;
• что сгенерированные упаковочные файлы согласованы с spec-файлом и раскладкой исходников.

Конкретные хэши в этом README не приводятся. При проверке обновления сопровождающим следует использовать штатный процесс верификации исходников.

Замечания по сопровождению в НАЙС.ОС

Перед обновлением пакета сопровождающим NiceOS следует проверить:

• заметки к релизу upstream, changelog и изменения в репозитории, которые могут повлиять на поведение пакета;
• требуется ли правка spec-файла из-за новых флагов сборки, переименованных файлов или изменённых путей установки;
• нужно ли заново сгенерировать исходники документации, man-страницы или другие производные файлы;
• сохраняется ли корректная установка имени бинарного файла и вспомогательных файлов;
• изменилось ли поведение, важное для терминального режима, работы с файловой системой или режимов с использованием базы данных; это следует проверять по upstream-документации, а не предполагать. (github.com)

К рискам относятся:

• изменения флагов командной строки или значений по умолчанию;
• изменения в генерируемой документации или man-страницах;
• изменения требований к сборке или структуре модулей;
• изменения формата вывода, способные повлиять на скрипты и автоматизацию.

Если какой-либо пункт неясен, его следует проверить по upstream-источникам до включения обновления.

Контрольный список сборки и проверки

Обычный контрольный список для RPM-сопровождения:

1. Подтвердить, что нужный набор upstream-исходников отражён в SOURCES/.
2. Проверить spec-файл на наличие патчей, списков файлов и секций установки.
3. Убедиться, что документация и man-страницы не требуют повторной генерации.
4. Собрать пакет в чистой среде.
5. Проверить, что собранный RPM устанавливает ожидаемый бинарный файл и документацию.
6. По возможности запустить доступные тесты пакета или upstream-тесты.
7. Проверить бинарный файл базовыми командами, например выводом справки и простым анализом каталога.
8. Просмотреть итоговый RPM на наличие неожиданных владельцев файлов, прав доступа или зависимостей.
9. Убедиться, что SRPM и бинарные RPM воспроизводимы в рамках принятого в репозитории процесса упаковки, если это применимо.

Ссылки

• Upstream-репозиторий (github.com)
• Upstream README (github.com)
• Upstream-материалы по установке (github.com)
• Upstream-документация по конфигурации (github.com)
• Upstream-исходник man-страницы (github.com)

Dist-git repository notes

• Package repository: rpms/gdu
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.