[HN Gopher] Oma: An attempt at reworking APT's interface
___________________________________________________________________
Oma: An attempt at reworking APT's interface
Author : yankcrime
Score : 48 points
Date : 2025-10-12 23:01 UTC (8 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ivolimmen wrote:
| This is a nice and fast interface. I normally use synaptic as I
| dislike the common 'Software' but this is a really nice command
| line interface.
| bayindirh wrote:
| There's always aptitude if you want a more powerful interface,
| too.
|
| aptitude can also handle extended states (autoinstall, manual
| overrides, holds, etc.) and can be used as a apt replacement
| (aptitude update).
|
| Also, aptitude can provide alternative solutions to harder
| package migration scenarios, showing all resolutions on a nice
| TUI.
|
| Wish the developers compared it with aptitude too, because I
| see no comparison there.
| ivolimmen wrote:
| Yeah I know of it's existence but I always forgot how the
| interface in aptitude works. It is not intuitive for me. I
| prefer apt for command line. 99% of the time I mostly use
| 'apt install x' and that is it. Changing a package to a
| specific version and other really niche stuff I will use
| synapic for. With this tool I can actually search and install
| and that is really nice. When I do not know the name of a
| package I needed to switch from command line to synapic as I
| do not know all commands to do so from the command line and
| that breaks my flow. One should not need to know all
| different options by heart of package manager on the command
| line, and with this I do not need to.
| bayindirh wrote:
| Note: This is not to discount oma of what it does, but to
| shed some light to how aptitude thinks about its workflow.
|
| > I always forgot how the interface in aptitude works. It
| is not intuitive for me.
|
| That's a fair criticism of aptitude, but let me give you a
| couple of hints, not to change your mind but to give some
| insights, how to use aptitude, if you prefer.
|
| First, aptitude is mouse aware. You can just click around.
| Packages, top menu, everything. To close menus you can you
| can press <ESC>. Alternatively you can press <CTRL> + T to
| toggle the menu and navigate with arrows.
|
| Management of packages with keyboard shortcuts is like
| this: + : Add / Install - :
| Remove _ : Purge = : Hold M : Mark
| auto m : Mark manual
|
| Makes sense if you ask me.
|
| Upgrading is equally straightforward. "u" for upgrading
| package lists and "U" for marking every upgradeable package
| to upgrade.
|
| I think of "g", which aptitude uses as "Next >" button, as
| (g)o.
|
| The solution of conflicts of other things also intuitive
| from my PoV. e for examine, "." for next, "," for previous,
| "!" for apply/force (think as "do as I say switch" in
| vi/vim).
|
| The only shortcoming of aptitude can be told as not
| searching package descriptions from the search interface,
| which can be opened with "/", which is search in almost any
| other CLI tool in Linux. Also, this search interface
| accepts regular expressions to match parts of the package
| names.
|
| Lastly, both apt and aptitude has bash completion for
| everything from switches to package names. apt(itude) can
| accept pretty convoluted command line switches, but I
| rarely use them, if ever.
|
| So yeah, this is how I think of and operate with
| apt(itude), hope it sheds some more light into these tools.
| Again, this is not to discount oma or change your mind, but
| a little cheat sheet.
|
| P.S.: aptitude has minesweeper built-in, because we used to
| use this thing on dial-up era, and waiting for packages was
| boring. A couple of rounds of it always brings some joy to
| late night waits.
| mingcongbai wrote:
| As a hint - there's a TUI interface to oma, just run `oma'
| without any parameter!
| self_awareness wrote:
| for fuzzy package search we can run `apt-cache search keyword |
| fzy` (fzy is a fuzzy pager).
|
| it of course works with Arch pacman -Ss, Gentoo qsearch, etc.
| imiric wrote:
| This looks nice, thanks for sharing.
|
| Though IMO the main issues with APT/dpkg are not related to their
| UI. It is their decades-old internals, and very limited support
| for transactional/atomic upgrades and rollbacks. Upgrading an APT
| system is the same launch-and-pray operation as on most Linux
| systems. I see that oma has an `undo` command, which is great,
| but I wonder how reliable that is in practice.
|
| I think that every modern OS should support safe upgrades and
| rollbacks. Nix and Guix are obviously built from the ground up
| with this in mind, but they both leave a lot to be desired as far
| as UX goes. Nix more so than Guix. It is these package managers
| that would benefit the most from a good UI/UX polish.
|
| So for a new OS/distro, I would start with a package manager with
| solid fundamentals, and work on refining their UI/UX, rather than
| do the same for one with fundamental issues such as APT.
|
| BTW, I was interested in learning more about AOSC, but the main
| site is in Chinese with no English translation, so I guess it's
| not meant for global use.
| happymellon wrote:
| https://wiki.aosc.io/aosc-os/is-aosc-os-right-for-me/
|
| I see both English and Chinese languages in their wiki.
| contrarian1234 wrote:
| That's like someone gives you a nicer car and you say "yeah but
| it doesn't fly". Having a better UI for APT is a separate goal
| from.. making the next package manager? or improving Nix?
|
| The reality is that Ubuntu LTS (and APT by extension) is pretty
| much the standard OS of Linux. Even if there are better
| solutions, that's sort of irrelevant. And APT users could use a
| better UI
| imiric wrote:
| > That's like someone gives you a nicer car and you say "yeah
| but it doesn't fly".
|
| No, not really. It's like someone giving you a car that looks
| like a Ferrari, but has the internals of a Fiat.
|
| To be fair, I'm not discrediting this project. I think it's
| great that someone is thinking about these things. I'm just
| saying that I would've started with a project with solid
| internals, rather than put lipstick on a pig.
| medstrom wrote:
| You make it sound as if it's pure aesthetics, but... an
| interface that makes it easier to undo a change is far from
| being lipstick on a pig, it's an upgrade in real function.
| ZeroAurora wrote:
| The AOSC team is working on website i18n recently, so check
| back later!
|
| You can visit the [wiki](https://wiki.aosc.io/) in the
| meantime.
| bobajeff wrote:
| Yeah not to knock their contribution but I was hoping they'd
| help make system package management as easy as npm package
| management. If I want to install say r-studio and octave apt
| will install a bunch of packages with dependencies. But what if
| I decide I don't want r-studio or any of the other stuff
| related to r on my system? I can't just do apt remove r-studio.
|
| This is why I I've been using conda, appimages and chroot jails
| lately. Still no solution though.
| craftkiller wrote:
| What doesn't `apt-get purge r-studio` accomplish? Are you
| saying you want your R/python files deleted too?
| everforward wrote:
| You can use 'apt autoremove' to remove transitive
| dependencies that aren't required anymore. I think you
| sometimes have to run it multiple times, though, because it
| won't recognize that a dependency of a transitive dependency
| is no longer required after removing the first transitive
| dependency.
| pantalaimon wrote:
| Yea dpkg installations are notoriously single threaded and
| laden with scripts.
|
| Compared to e.g. Alpine's apkg, installations take quite some
| time.
|
| Installing multiple (independent) packages in parallel would
| seem like a straightforward improvement - or installing while
| downloading unrelated packets.
| contrarian1234 wrote:
| Can someone involved with packaging help me understand why
| dependency management and system configuration are integrated and
| not separate things entirely?
|
| For instance, if I "install" LXQT on Ubuntu LTS, it's going to
| not only install all the dependency libraries (and the
| dependencies' dependencies) as well as all the relevant
| executables.. but it's also going to go around and change a bunch
| of configurations so that when I boot LXQT boots instead of
| whatever I used before.
|
| Why would it not make sense to have installing
| libraries/executables and their dependencies be decoupled from
| all the twiddling config files and setting up the spiderweb of
| userland processes?
| bbarnett wrote:
| This isn't true.
|
| debconf plus update-alternatives plus display manager login
| menus means configs are sticky.
|
| There are rare exceptions, but unless Ubuntu is very strange,
| deviating fron Debian significantly (and stupidly), what you're
| saying doesn't happen.
|
| And it _is separate_. The package manager is calling update
| alternatives. It 's not some ad hock wild west.
|
| You're either asked, or alternatively no change is made.
| bayindirh wrote:
| > it's also going to go around and change a bunch of
| configurations so that when I boot LXQT boots instead of
| whatever I used before.
|
| This because you left the alternative in "auto" mode, or the
| installed package called update-alternatives and changed the
| config forcibly.
|
| Debian doesn't change alternatives during package installations
| without consulting to you if there's a TTY attached. Installing
| vim doesn't change "editor" to vim, or installing most doesn't
| change "pager" to most (unless the configs are in auto mode and
| the package you installed has a higher priority on that
| alternative list).
|
| Also, when working with apt(itude), the changes are visibly
| done, saying that "update-alternatives: x has changed to
| new_program (auto)" or something similar.
|
| So nothing is hidden from you, and why apt has a rolling log so
| you can review things even after it's completed.
| everforward wrote:
| It's mostly about user intent. If you install the LXQT binaries
| on Ubuntu, you probably intend to use LXQT as your DE. It makes
| sense to set that up for you.
|
| There's also an accessibility aspect. Novice users are likely
| to struggle with setting up the configs, so auto-configuring
| the packages makes them more accessible to novices. Wanting to
| install a package without configuring it is a poweruser kind of
| request; it makes sense to require poweruser knowledge to get a
| poweruser install, rather than making poweruser-style installs
| the default.
|
| Fwiw, I believe most package managers can be told to not run
| their configuration steps if you really want that.
| majorbugger wrote:
| I'm really disappointed that it's yet another tool that requires
| "curl into bash" to install, even when you're building from
| source.
| mingcongbai wrote:
| I mean, it's not required per se, it's right there in a
| repository... the script configures the repository and installs
| oma afterwards (there are system dependencies).
|
| https://repo.aosc.io/oma/
|
| Out of curiosity, how - by your preference - should this be
| done so that it's easier for the user?
___________________________________________________________________
(page generated 2025-10-20 23:02 UTC)