In my time using debian, I've seen a few things with updates that I was never really sure how to formulate into a search query, but didn't bother me enough to ask here about them. Until today. Just a few questions:


1) If I run an update, and see that things are being held back, how do I force them to install?

1.1) If many things are being held back, is there a way to force install only a few of them?

2) On wheezy, when I run an update if the total installed size is less than a certain size, it doesn't prompt. Is there a setting somewhere that I can set to ALWAYS prompt before installing?

3) Sometimes things will show "The following extra will also be installed." Is there an easy way to specify out of the extra packages which ones to install and which ones to pass over? I know I could just do --no-install-recommends but that doesn't catch all the extras, and then I have to go back and install each one individually which is tedious.

3.1) Right after the "extra packages" there is "Suggested packages." Is there a simple method (aside from manually 1 by 1) installing only some of the suggested packages? I know there is --install-suggests but that installs all of them, and I'd like to do only a few.

1) If they are held back, and are installable, try apt-get dist-upgrade. This will install any packages that are dependencies to complete the upgrade (apt-get upgrade will not install dependent packages).

1.1) You can use apt-get install to install the packages you want to. You'll have to specify the packages on the command line. Tedious, but exact. This is the pretty much the same for your Q2 and Q3. You don't have the option of "I only want to install package X and Y, although apt suggests X, Y, and Z". Unfortunately you accept all of apt-get's actions or none. As far as recommends and suggests go, taking some of them is going to be a manual affair.

With package installation and conflicts, aptitude allows you to choose from various scenarios, if more than one is available, but still it's take all of what it suggests for conflict resolution, or nothing.

Perfectly concise. Thanks!

As far as the dist-upgrade goes, if I am upgrading 1 specific package, and it has a bunch of other packages with it that need to upgrade as well (for example, if I upgrade a DE like gnome), but some of those secondary packages are held back, if I run dist-upgrade the entire system is upgraded. Is there a way to just do that for a specific package list?

Usually when I want to accomplish that, I just use:

If there's a newer version of the package, it will upgrade that package and it's dependencies. No other upgrades will be done. You can specify more than one package, so just list those you want upgraded. apt-get will upgrade the dependent packages as necessary.

Yeah, one by one, that's what I thought. Tedious but if that's what works, that's fine by me. Was just hoping there was some built in apt function for this that I was unaware of.

Thanks for your input!

apt-get dist-upgrade will upgrade the package(s) held back if they need a new package(s) installed or if they need a package(s) removed.

Will also not upgrade some packages, rarely happens in a Stable install but will in testing or unstable, if needed depends have not hit the repo yet.

See the man page for apt-get. Also for apt which is really loosy but suggests some others that will be helpful.

man pages are great, and I often refer to them, but they can often be very ... dense, and don't always explain things as thoroughly or simply as possible. Do you happen to know of any good resources like "man expanded" or "man simplified" or something?

Not really. Many people would like that. The idea of the newer "info" pages is an attempt in that direction. They are invoked the same why man pages are but many are currently identical to the man pages.

The real problem most of us have with man pages is a language problem. They are written in Geek and many of us are not native Geek speakers.

The problem with most sites that try to simplify, or put man pages or other matterial about Linux in "plain language" is that;
A>these are technical issues and all technologies have their own vocabulary because no other really gets the meaning across.
B>the people doing the simplification don't have full understanding of the issue they are writing about and possibly not as much as you do. They write very well and this makes it look like they know what they are talking about. This leads to wrecks.

Basically if you are going to rebuild, say, a car engine you need to learn the language. The same is true of working with any technology including computers.

In Linux you are the system admin in fact instead of in fantasy as with Windows. To do this you really do need to have more knowledge and package management is one of them.

In Slackware there is no "package manager" to do some of this for you as with the RPM or APT systems in the Red Hat and Debian branches of Linux. These systems deal with depends and where all the parts of the package go in the file system. You can therefore deal only with the binary packages.

These systems do need to be run though and the only way to do that is to learn the language used to both run and describe the system.

This is the main reason I suggest people find at least one of the branches of Linux and stick to it until they get very comfortable with the package management system. This is because they all have one thing that they do and that is to get a binary installed in the file system. To do this they have to, in one way or another accomplish the exact same things. Once you are comfortable and understand a good bit about one system the others are a lot easier to comprehend even though they appear quite different. They aren't, the language is different.

I, for instance, am somewhat fluent in the language of APT and can get around in Urpmi (used in Mandrake offspring like Mandriva and Mageia). Can with careful planning and time do compiling. None of these are hard, they do take practice and familiarity.

The only way to get familiarity is to use them and read the documentation written by people that developed and maintain them. All other documentation is more like a travel brochure being used to study a foriegn countries legal system.

At least this is how it seems to me after trying to make sense of things written in "plain language" myself for way too long.

This is something I have been pondering since I wrote a thread back a while ago about contributing to documentation. I'm trying to find that balance of being technically accurate, and yet easy to read. It's harder than it seems, believe it or not. It's really hard to not fall into getting overly technical. Maybe this is unavoidable for some subjects, but I'm not giving up yet. One of my early attempts would be http://wiki.linuxquestions.org/wiki/Tilde_expansion, and as you can see, while not overly technical, it's not exactly plain English either.

Now you're speaking my language *timallenesquegrunt*

With the primitive form of Windows' UAC, I don't see this distinction as so great anymore.

Agreed. I have been using Debian and derivatives for years. Friends have suggested I try Fedora, Arch, etc... It's very hard to switch once you're comfortable. It's not impossible, but when you're familiar and the tool does what you want, there's little reason to switch. Stuff like compiling from source and configuring and still be done, just in different ways (besides, nobody else has something similar to debconf when you just want to get something configured and don't want to hand edit).

What we need is people dedicated to doing it that way. However it's harder for smaller projects to fit in a writer, as some of the larger projects have their own documentation teams.

I'd never heard of info before, interesting tool.

As for geek speak, I think it's more that people don't speak the same dialect of geek that each individual package developer speaks.


This is actually a benefit of Slackware in my opinion. No package manager means you have to learn the ins and outs of manual package management, which then can lead you to understanding auto-package-managers better.

I have been running debian based systems for a while and have been doing what I can but haven't found many reasons to mess with the advanced sides of apt. S'pose I should do that before I move on to rpm package managers. I really should read through the deb handbook more but I don't think that has as much detailed descriptions of the advanced sides of things.

Yes. What you say about Slackware is dead on.

This is the reason I have left it alone. I have performed all the needed steps for installing from source. I have no doubt about my ability to do this to install anything I may want that is not included on the install image.

It is just that there are so many other things I want to learn about. I am not sure that I actually did not make a mistake not switching to it when I left Ubuntu. Could be I would be closer to where I want to be than I am now.

I laid out a plan of what I want to learn and I am not going to change it now. I went through the distro hopping phase and it is simply silly. There isn't, except for package management, much difference.

Slack is going to be my next "new" distro. When I get my new box built it will be on there within a month. On an internal drive even.

I have a system of testing out different distros and they almost always start on an external and are visited freqently but not for long.

My main drive is what gets used. My other internals get installs of things, perhaps simply copied from the externals, that I want to spend some time with. They don't get visited as frequently as the externals. They get serious time spent on them when I do go to them though.

Slack looks interesting enough to me to go on the second drive right now. It may end up on it and an external where I will abuse it a bit more or try out what ever they use as a "testing" version.

Who knows? May be time to move on.