GRPM Development Roadmap & Community Discussion

[kolkov]

GRPM Development Roadmap & Community Discussion

Current Status

v0.1.0 — Initial public release (January 2026)

This is an MVP (Minimum Viable Product) — a working foundation for community feedback. Core functionality works, but there's much to improve.

---

Architecture Decisions for Discussion

1. Daemon: Why and When?

Why GRPM has a daemon mode:

Use Case	Standalone CLI	With Daemon
Simple install/remove	✅ Works	✅ Works
Parallel operations	❌ Manual	✅ Job queue
Package cache	Cold start each time	✅ Warm cache
GUI/IDE integration	❌	✅ IPC via gRPC
Scheduled sync	❌	✅ Background
System monitoring	❌	✅ REST API

Key point: Daemon is optional. CLI works perfectly standalone. Daemon adds value for:

• Desktop environments wanting package management integration
• Tools like qlop equivalents
• Scheduled background updates
• Development/monitoring dashboards

Question for community: Is this useful? Or should we simplify and remove daemon entirely?

---

2. REST API: Port & Socket Discussion

Current implementation:

• gRPC: Unix socket /var/run/grpm.sock ✅
• REST: TCP port 127.0.0.1:8080 ⚠️

Community feedback:

• Port 8080 conflicts with web development (webpack-dev-server, etc.)
• Nix/Guix use Unix sockets exclusively — works well
• Why not Unix sockets for REST too?

Options:

Option	Pros	Cons
A. Configurable port (default != 8080)	Backward compatible	Still uses ports
B. Unix socket for REST	No port conflicts, like nix	Some HTTP clients need adaptation
C. Both (socket default, port optional)	Maximum flexibility	More code to maintain
D. Remove REST, gRPC only	Simpler	Loses easy curl/browser debugging

Proposed solution: Option C — Unix socket by default (/var/run/grpm-api.sock), optional TCP port via config.

Alternative ports suggested: 5137, 8187, 31337 (if TCP needed)

---

Development Roadmap

Phase 1: Stabilization (v0.2.x)

Focus: Fix issues found by community, improve usability.

• Configurable API endpoint (socket/port selection)
• Better error messages with actionable suggestions
• Improved documentation — more examples, troubleshooting
• Bug fixes from community reports
• Test coverage increase (target: 80%+)

Phase 2: Compatibility (v0.3.x)

Focus: Better Portage compatibility.

• Full EAPI 8 support
• Extended eclass support (more than toolchain-funcs, eutils)
• CMake build system
• Meson build system
• Ninja support

Phase 3: Performance (v0.4.x)

Focus: Optimization for large systems.

• Parallel package builds (--jobs improvements)
• Dependency resolution caching
• Incremental sync (only changed ebuilds)
• Memory optimization for large dependency graphs

Phase 4: Ecosystem (v0.5.x+)

Focus: Integration and tooling.

• Web UI for daemon (optional package)
• Plugin system for custom build systems
• Emerge wrapper for full Portage CLI compatibility
• Migration tool from Portage

v1.0.0: Production Ready

Requirements (no fixed date):

• API frozen and stable
• Community validated on real Gentoo systems
• No critical bugs for extended period
• Complete documentation
• Security audit passed

---

How to Contribute

Good First Issues

1. Documentation — improve examples, fix typos
2. Error messages — make them more helpful
3. Test coverage — add tests for edge cases
4. Bug reports — with reproduction steps

Medium Difficulty

1. New eclass support — implement missing eclasses
2. Build system support — CMake/Meson handlers
3. Performance profiling — identify bottlenecks

Advanced

1. EAPI 8 features — implement missing functionality
2. Parallel builds — job scheduling improvements
3. Plugin architecture — design and implement

Getting Started

# Clone
git clone https://github.com/grpmsoft/grpm
cd grpm

# Build (requires Go 1.25+)
make build

# Run tests
make test

# Run linter
make lint

The codebase is ~60K lines of straightforward Go. No magic, well-documented, follows standard conventions.

Resources:

• CONTRIBUTING.md
• ROADMAP.md
• Architecture

---

Open Questions

1. Daemon necessity — keep optional daemon or simplify to CLI-only?
2. REST API transport — Unix socket, TCP port, or both?
3. Priority features — what should v0.2.0 focus on?
4. Portage compatibility — which commands/features are most needed?

---

Let's build this together! Share your thoughts below.