The apt command: Combining apt-get and apt-cache and adds a progress bar (2014) | Hacker News Reader

The apt command: Combining apt-get and apt-cache and adds a progress bar (2014)

mvogt.wordpress.com

175 pointsJelteF74 comments

I've never understood why debian insists on having these be different commands. It would make sense if install, search, upgrade and uninstall were all discrete, but the way it is today feels half implemented.

Same. Having to search for what you wanted to install via apt-cache, but then actually install it via apt-get, was a triumph of some unexplainable factor over usability.

Not sure why you were downvoted, I agree 100%. I try to use aptitude CLI for exactly this reason.

I want to say it has to do with keeping each "idea" as a separate program, but the fact that apt-get can install, uninstall, list packages, etc. seems to go against that idea

And remove an application with apt-get? I prefer yum and dnf much over apt.

Only one of them requires readwrite system administrator privileges (eg sudo). apt-cache can be run by any user as it doesn't expose any secret data and can't be used to make changes. apt-get can install and uninstall software as well as download packages and thus needs root privileges in the classic UNIX model.

apt-get source works fine without super-user privileges, so it isn't just that some have to be run as root.

apt-get doesn't fail when run as non-root, it only fails when you run it as non-root when you try to some of the commands that require root privileges (such as installing system level packages). It has lots of commands that don't need root privileges. I don't see much reason why "list all the packages available for installation", as well as the other commands in apt-cache, aren't included in that list.

On CentOS, I can do "yum search something" as a regular user, while "yum install something" or "yum upgrade" require root privileges.

I think it's similar with the pkg command on FreeBSD.

and same with pacman on Arch (and derivatives)

Same here, I've always found them strange.

In contrast, pacman or guix are quite intuitive and feel better designed.

I hear you. Back when I was on debian I had a small script I called apt-o ('o' for oblivious) which combined the two -- as you mention.

"aptitude [...] is a friendly frontend to apt."

"The primary command line tool is aptitude. apt-get fulfills a similar purpose and although it is no longer the recommended primary tool some still use it."

If you prefer the apt-* commands: "You can also use Wajig, for an unified and more logical command-line interface to all package management functions." (Apparently, apt is the new Wajig, except that apt doesn't automagically sudo, which Wajig did.)

See https://wiki.debian.org/DebianPackageManagement

Yeah, until you do an upgrade:

"The upgrade process for some previous releases recommended the use of aptitude for the upgrade. This tool is not recommended for upgrades from wheezy to jessie."

See https://www.debian.org/releases/stable/amd64/release-notes/c...

Debian's zigzagging between package management frontends (dselect, apt-*, aptitude, dpkg, now apt?, … all in use in parallel) is incredibly frustrating. Pacman e.g. is so much easier to use because everything's in one well-structured command.

It probably reflects the classic problem of developer turnover in OSS projects and the resulting approach to technical debt. Old developers fade away, young guns come through (often still in academia), "this code is all crap, let's chuck it out and build something better, how hard can it be?"...

Well, just use apt(8):

apt install - Install packages

apt remove - Remove packages

apt upgrade - Upgrade packages without removing

apt full-upgrade - Upgrade packages, allowing removals

apt update - Refresh sources

apt show - Show a package

apt list - List packages, you can filter by stuff like --installed or --upgradable

1. "Just use $newtool" has been Debian's spiel for every past release, and every time it's a different one.

2. Why full-upgrade and not dist-upgrade like in all the other debian package managers? Would that little bit of internal consistency really have hurt?

3. Still does not seem to cover all use cases.

I don't know what you mean. dselect is like 2000 era, and was replaced by "aptitude" at least 15 years ago. "apt" has been around since the beginning and still works just fine. The fact that "aptitude" has some overlap with "apt" is a detail--its real strength is that its curses ui (which was a massive improvement over dselect).

The way I see it, the distinction is that apt-get requires the network to be up, whereas apt-cache, as the name suggests, doesn't.

Except for "apt-get remove".

There's another thing about apt that's bothered me: apt-cache search isn't a very good search engine. Its most common use case is finding the exact name of some library/framework package, ie, "apt-cache search someframework". For common frameworks, this produces hundred of search results for packages that use the framework and mention this in their description, while the framework itself is in the list but very difficult to find. The --names-only flag fixes this, but it's not the default so it's one more thing to worry about.

I have this problem too. If I did myself shelling out to grep with pcre flags to find a simple library then there's a UX issue.

> If I find myself shelling out to grep with pcre flags, I am using unix pipes as intended

Fixed that for you.

Hmm...except that I would guess search should do one thing well -- searching. Which, incidentally, using --name-only and/or regex, it does.

Search uses regular expressions so generally no need for grep unless you need more complex filters; --names-only has the -n short-form:

  apt-cache search -n <regexp>

More generally apt-get and apt-cache are designed to be backward-compatible for use in scripts whereas apt is not[0]:

  SCRIPT USAGE AND DIFFERENCES FROM OTHER APT TOOLS

       The apt(8) commandline is designed as an end-user tool and it may change behavior between versions. While it tries not to break backward compatibility this is not guaranteed either if a change seems beneficial for interactive use.

[0] http://manpages.ubuntu.com/manpages/xenial/en/man8/apt.8.htm...

Great tip thank you!

Will it take twice the amount of time with the progress bar enabled?

I can't answer specifically for `apt`, but many commands take significantly longer if you let them display to stdout versus piping their output to a file or `/dev/null`. cf.:

  $ time ls -R /usr
  real    0m7.570s
  user    0m0.104s
  sys     0m2.286s

  $ time ls -R /usr > /dev/null
  real    0m0.193s
  user    0m0.036s
  sys     0m0.154s

(edit: when will I grok HN markup?? cough support markdown cough)

Did you run those two commands in sequence? Did you account for disk-cache effects? Try running it 4 times, alternating the versions and see what your last 2 times are ...

All valid points, but (anecdotally) over the past several years of work, this holds true.

You can actually show different speeds in different terminals - the speed of terminal rendering affects the duration of the test. In the tests below, I have no custom terminal prompts or similar (no git status lines etc) - they're all distribution defaults running bash.

    # all the below run in the same MATE desktop
    # lxterm (from lxde - is easiest on my eye)
    $ time ls -R /usr
    real    0m19.974s
    user    0m0.860s
    sys	    0m0.832s

    # gnome terminal
    $ time ls -R /usr
    real    0m19.902s
    user    0m0.800s
    sys     0m0.776s

    # xterm (yes, it really is 10x the speed)
    $ time ls -R /usr
    real    0m1.872s
    user    0m0.856s
    sys     0m0.800s

    # rerun in the first terminal, and the time hasn't changed - still 19s

    # now in lxterm redirecting to null
    # (and xterm gives similar results here)
    $ time ls -R /usr > /dev/null

    real    0m0.418s
    user    0m0.256s
    sys     0m0.156s

All that prettification and rendering takes time; if you want raw speed, use xterm... or pipe output to /dev/null.

Interestingly, 'time' on gterm and lxterm had tabs between the above field:value pairs (I had to reformat to show them nicely), but xterm used spaces. I don't know enough about the terminal underpinnings to guess as to why.

I've always assumed something like the above is slow due to the terminal blocking the program to perform updates to the display.

Whereas a status indicator isn't exactly pushing much data to the terminal. So, It shouldn't impact run time.

Yes, that's a reasonable assumption. I am by no means a terminal guru, but my understanding is that, for something like a progress bar or spinner (anything that is updated in-place in the terminal), the entire "screen" is being redrawn on update.

I also suspect (though have not verified) that any output to terminal is quite a bit slower than the raw operation -- that sort of difference that we should all know, as programmers.

http://norvig.com/21-days.html#answers

also don't forget apt-file (very useful to find out which package contains the library/binary you want to install) and dpkg -L to figure out what a particular package installed on your system.

I switched to debian some time ago and it's interesting so many different commands are used for package management, this said I personally have an alias ap=sudo aptitude -t jessie-backports alias and use that as a command line interface for search/install, and run the full aptitude gui only when doing updates

Yes to apt-file, and 'apropos' seems to fit in there too (searches for keywords in package descriptions).

Replying because can't edit: "apt search $keyword" works like apropos but isn't in the tab completion on my Kubuntu 15.10.

v1.1: https://mvogt.wordpress.com/2015/11/30/apt-1-1-released/

I've already been using wajig for years now. It combines these two and about a dozen other utilities into one command.

Wow, I've never heard of this, pretty neat! Thanks for sharing.

Wonder how it compares to aptitude? Used to be (10 years ago), aptitude was better and not orphaning packages on removal. Been using ever since..

Really cool. Somehow I had missed the introduction of this but it's a friendlier interface and already on my Ubuntu systems.

Same here, I can't believe we're a few years late. Much better than the apt-get / apt-cache stupidity.

Harsh, this must have really upset you.

Perhaps not upset, just intolerant of really lame, unintuitive crap software?

If you'd like to try this right away (not have to wait) on any version of Debian/Ubuntu (just need pip) try this script I wrote several years ago:

https://pypi.python.org/pypi/apt-wrapper/

No prog bar but it handles all common tasks, ppa's, and elevates with sudo automatically. For example:

    > pip install apt-wrapper 
    > apt in foobar

Here is my "apt-upgrade.sh"

    apt-get -y update
    apt-get -y upgrade
    apt-get -y dist-upgrade
    apt-get -y autoremove

I run that everyday.

https://wiki.debian.org/UnattendedUpgrades

Thank you a lot!

You missed autoclean. I typically only run autoremove upon reboot.

You can also set the update to happen automatically so that all you have to do is run upgrade.

Thank you for "autoclean". I'll check that.

> You can also set the update to happen automatically so that all you have to do is run upgrade.

I'm in "testing". Sometimes, even with "-y", I'm asked to validate some messages (often inside a vi prompt).

FYI

http://askubuntu.com/questions/3167/what-is-difference-betwe...

It cleans out unnecessary packages.

All the update does is download the latest available updates so it should not be prompting. My experience is that only upgrade/dist-upgrade will prompt.

I've got a VM running ubuntu 16.04-beta and it seems to be fine.

Thank you for the link.

> My experience is that only upgrade/dist-upgrade will prompt.

dist-upgrade every day, really ? That's a recipe for trouble, unless you're running Sid, which means you're already in trouble.

Source: my previous life.

Sid is unstable, isn't it?

I tried it a bit but it's very (very) unstable :-)

I come from Fedora and have few months only on debian. Still a rookie.

Yeah, Sid is the rolling unstable. It's still slower and relatively more stable than most rolling distributions, but it's constantly changing here and there and everywhere. Using it as your main desktop machine is a recipe for trouble, especially when major changes start rolling in. The only certainty with Sid is that your disk will work a lot because of the firehose of updated packages streaming in at every hour...

> .. It's still slower and relatively more stable than most rolling distributions ...

My experience is a "non-beta" Fedora is less stable than a "testing" debian.

> ...Using it as your main desktop machine is a recipe for trouble ...

Yes! It's a nightmare especially with Gnome Shell.

I see memory corruptions for months in Gnome windows. I wonder if it's related to Wayland stuff. It often occurs in Firefox.

I'd run a distributed for the fact that all was one command alone

I do something similar, but use

    aptitude -y safe-upgrade

...which is less likely to break things. Every month or so I go into aptitude to manually sort things out that have gotten their dependencies wedged.

> aptitude -y safe-upgrade

Interesting. My use of aptitude is limited to "search" so far.

Did you see that?

https://news.ycombinator.com/item?id=11230828

I love this, but its terminal magic isn't working properly for me. "apt install stuff" places a progress bar at the moment, then prints some misaligned stuff and then finally manages to clear the screen (!).

Any terminal settings I need to adjust? I'm using OS X's Terminal.app, terminal declared as xterm-256color, via SSH, under zsh.

Why not just alias apt=aptitude?

Yea... My thoughts as well?

apt has colors, aptitude doesn't… ?

aptitude has a nice curses interface, though, which is great for resolving conflicts or other changes that require planning

It also usually seems to be slower to start (at least in my experience) -- I tend to not like to use it except for resolving broken packages (since it's the nicest way to do that).

The latest version in Debian unstable (0.7.7) seems to have brought some improvements in startup time. Generally the recent progress has been very nice.

I had no idea about this and I maintain (only) Debian and Ubuntu based clients everyday..

Is this installed by default on Debian? If not, then this is a deal-breaker for me. I might as well install aptitude which also provides a similar command line interface.

It's provided by the same package as e.g. apt-get and apt-cache, so yes.

Thanks for the info, appreciate it!

i like the recent changes in debian. finally most of the use cases are covered

Finally! why has this taken so long? Common sense people

Reply on news.ycombinator.com