brianthehughes Logs are best for error messages, imo. ;-) Instead, it would be better to use tables instead of logs.
Features enabled by tables
- History Browsing: Query what packages were installed or removed in any transaction.
- Rollback: Undo a specific transaction by reverting to the previous state.
- Conflict Resolution: Analyze dependencies and conflicts by querying past transactions.
- Custom Reports: Generate detailed reports on package activity.
You are correct, we don't need a new tool, but making it more approachable would be beneficial. Here a better breakdown of ideas.
Rethinking pkg: A Simpler, More Modern Tool
The FreeBSD pkg utility, which GhostBSD uses, does its job. Written mostly in C, with SQLite for storage and some shell scripting and Lua sprinkled in, itâs functional but fragmented. It works, but it could work better, not by reinventing the wheel but by improving how we drive it.
The Current State
pkg handles core tasks like installing, upgrading, and managing dependencies. It stores metadata in SQLite, wraps operations in C, and relies on shell scripts and Lua for system hooks and configuration. The result? A multi-language toolkit that feels dated and harder to maintain in todayâs world.
The challenge isnât the packages themselves, the .txz format and metadata handling are solid. Itâs the tool. We donât need to tear it down, just make it smarter, cleaner, and more approachable.
The Goal
Aim for a better pkg tool. Letâs make it:
- Unified: Replace the patchwork of C, Lua, and shell scripts with one modern, easy-to-use language.
- Capable: Add features to address the common frustrations of todayâs
pkg users.
- Modern: Choose a language like Go or Rust to build a tool thatâs fast, secure, and easy to extend.
This isnât about complexity; itâs about clarity and making it more accessible to new developers and with features typically found with other package managers.
Why Go or Rust?
These languages offer what pkg needs: modernity, efficiency, and simplicity.
- Go is straightforward. It compiles fast, handles concurrency like a pro, and comes with a rich standard library for tasks like networking and file handling. Itâs a natural choice for a tool that needs to be lightweight and scalable.
- Rust is precise. Its focus on safety and performance makes it ideal for critical systems. If
pkg needs memory safety and raw speed, Rust delivers.
Either language consolidates the toolâs functionality, eliminates unnecessary complexity, and provides room to grow.
The Features That Matter
Letâs focus on solving problems, not just adding buttons:
- Transaction History: Show users what happened and why. Roll it back if needed.
- Group Management: Install, update, or remove packages in groups, not one by one.
- Better Repository Handling: Enable, disable, and query repos with a single command.
- Cleaner Logs: Make logs searchable and auditable.
- Smoother Dependency Management: Resolve conflicts before they cause chaos.
These arenât radical ideas. Theyâre overdue.
The Road Ahead
- Keep the Core: No need to change the
.txz format or the repository structure.
- Build a New Tool: Start fresh with Go or Rust. Focus on feature parity first, then add improvements.
- Stay Compatible: Ensure the new tool works seamlessly with existing packages and workflows.
- Iterate, Donât Overhaul: Roll out changes gradually, listening to the community at every step.
The Bottom Line
GhostBSD deserves tools that feel modern without sacrificing stability. A better pkg isnât a monumental task, itâs a series of small, deliberate improvements. With a single, more approachable language and a focus on solving real problems, we can deliver a package manager thatâs not just functional but delightful to use.
And knowing the GhostBSD community? The less frustrating the process, the better.
