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

175 pointsby JelteF10 anni fa74 comments

mvogt.wordpress.com

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

https://mvogt.wordpress.com/2014/04/04/apt-1-0/

76 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.

CydeWeys10 anni fa

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.

Drdrdrq10 anni fa

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

colejohnson6610 anni fa

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

jafingi10 anni fa

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

adricnet10 anni fa

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.

[deleted]10 anni fa

krylon10 anni fa

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.

konfou10 anni fa

and same with pacman on Arch (and derivatives)

pherq10 anni fa

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

CydeWeys10 anni fa

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.

currysausage10 anni fa

"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

miken12310 anni fa

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...

creshal10 anni fa

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.

toyg10 anni fa

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?"...

julian-klode10 anni fa

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

creshal10 anni fa

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.

__david__10 anni fa

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).

nextos10 anni fa

Same here, I've always found them strange.

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

hndl10 anni fa

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.

asymmetric10 anni fa

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.

__david__10 anni fa

Except for "apt-get remove".

jimrandomh10 anni fa

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.

matt_wulfeck10 anni fa

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.

dsl10 anni fa

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

Fixed that for you.

davvolun10 anni fa

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

iam-TJ10 anni fa

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...

matt_wulfeck10 anni fa

Great tip thank you!

robin__10 anni fa

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

clebio10 anni fa

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)

jasonjayr10 anni fa

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 ...

vacri10 anni fa

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.

clebio10 anni fa

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

josho10 anni fa

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.

clebio10 anni fa

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

clebio10 anni fa

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.

tetraodonpuffer10 anni fa

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

pbhjpbhj10 anni fa

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

pbhjpbhj10 anni fa

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

enesunal10 anni fa

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

rcthompson10 anni fa

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

joshstrange10 anni fa

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

esaym10 anni fa

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..

ianlevesque10 anni fa

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

nherment10 anni fa

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

cryowaffle10 anni fa

Harsh, this must have really upset you.

dave200010 anni fa

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

mixmastamyk10 anni fa

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

vmorgulis10 anni fa

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.

saltvedt10 anni fa

https://wiki.debian.org/UnattendedUpgrades

vmorgulis10 anni fa

Thank you a lot!

newman31410 anni fa

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.

vmorgulis10 anni fa

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).

newman31410 anni fa

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.

vmorgulis10 anni fa

Thank you for the link.

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

__david__10 anni fa

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.

vmorgulis10 anni fa

> 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

toyg10 anni fa

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.

vmorgulis10 anni fa

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.

toyg10 anni fa

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...

vmorgulis10 anni fa

> .. 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.

JBReefer10 anni fa

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

lobster_johnson10 anni fa

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.

mikelward10 anni fa

Why not just alias apt=aptitude?

quadrangle10 anni fa

apt has colors, aptitude doesn't… ?

lorenzhs10 anni fa

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

pherq10 anni fa

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).

lorenzhs10 anni fa

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.

deelowe10 anni fa

Yea... My thoughts as well?

HeadlessChild10 anni fa

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

Drdrdrq10 anni fa

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.

rincebrain10 anni fa

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

Drdrdrq10 anni fa

Thanks for the info, appreciate it!

0x006A10 anni fa

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

exprI10 anni fa

yahyaheee10 anni fa

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