Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
Building tag database... Done
The following packages have been automatically kept back:
gnome-panel language-support-writing-ru
The following packages have been kept back:
f-spot gnome-applets grub initramfs-tools linux-generic linux-headers-generic linux-image-generic
linux-restricted-modules-generic udev xserver-xorg
0 packages upgraded, 0 newly installed, 0 to remove and 12 not upgraded.
Need to get 0B of archives. After unpacking 0B will be used.
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
Building tag database... Done
Why is it keeping back those packages?
--
Due to extreme spam originating from Google Groups, and their inattention
to spammers, I and many others block all articles originating
from Google Groups. If you want your postings to be seen by
more readers you will need to find a different means of
posting on Usenet.
http://improve-usenet.org/
> When I try an upgrade of my 8.04, it says:
...snip...
> Why is it keeping back those packages?
Package database requires something not requested. Execute
apt-get dist-upgrade
That's not necessary. It keeps back any packages which get split, or which
require the introduction of previously absent packages (e.g. when a package
gains a new dependency). This is because it is trying to keep "upgrade"
meaning just that - upgrade installed packages, but don't install new ones.
You'll find that if you do "apt-get install packages" on the packages which
have been kept back, that will pull in all the additional new packages and
complete the upgrade(s).
CC
I think that this is what was missing. thanks
> "Dave Uhring" <daveu...@yahoo.com> wrote in message
> news:pan.2008.05.04....@yahoo.com...
>> On Sun, 04 May 2008 09:58:25 -0500, Ignoramus11115 wrote:
>>
>>> When I try an upgrade of my 8.04, it says:
>> ...snip...
>>> Why is it keeping back those packages?
>>
>> Package database requires something not requested. Execute
>>
>> apt-get dist-upgrade
>
> That's not necessary.
That is one of the steps directed by the update tool and it sometimes
works.
Indeed. I don't disagree with that at all, I'm just pointing out that it's
not necessary. "dist-upgrade" is a whole lot more than plain old "upgrade",
and you don't need to do it just because "upgrade" holds back a few
packages. You can use apt-get install for those packages instead.
CC
>>>> apt-get dist-upgrade
>>>
>>> That's not necessary.
>>
>> That is one of the steps directed by the update tool and it sometimes
>> works.
>
> Indeed. I don't disagree with that at all, I'm just pointing out that it's
> not necessary. "dist-upgrade" is a whole lot more than plain old "upgrade",
> and you don't need to do it just because "upgrade" holds back a few
> packages. You can use apt-get install for those packages instead.
Two days ago I had about 30 packages held back. Should I have run
apt-get install for each of them? : >
I get this quite often - it usually boils down to three or four key installs
of high-level packages which then pull in many of the others (kde, kdm,
kdesktop are obvious candidates). Occasionally I have to do a dozen or so
installs to tidy up all the small fry, so maybe it would be better if I got
to grips with dist-upgrade instead.
CC
> I get this quite often - it usually boils down to three or four key
> installs of high-level packages which then pull in many of the others
> (kde, kdm, kdesktop are obvious candidates). Occasionally I have to do a
> dozen or so installs to tidy up all the small fry, so maybe it would be
> better if I got to grips with dist-upgrade instead.
apt-get dist-upgrade does no harm and it may solve the problem - in fact
it usually does.
Because they don't let morons have anything they can f*ck up. Your name is
on the list a**hole
I remembered why I never use dist-upgrade. I am waiting for gkrelltopd to
stop depending on libc-dev, so I actually want it kept back.
CC
> I remembered why I never use dist-upgrade. I am waiting for gkrelltopd to
> stop depending on libc-dev, so I actually want it kept back.
libc-dev is one of the *first* packages I add after a fresh install : >
Interesting! Mine are sudo, less and openssh-*
I tend to divide machines into Production and Development. The latter would
certainly have libc-dev installed pronto, but Production machines don't have
any -dev packages installed.
Besides, it's a point of principle. Gkrelltopd is essentially one 8k .so
file, so having it depend on 17MB of libc6-dev and linux-libc-dev is insane.
If I want bloatware I'll run Windows.
CC
>> libc-dev is one of the *first* packages I add after a fresh install : >
>
> Interesting! Mine are sudo, less and openssh-*
I have never used sudo and don't intend to so. Etch has less installed by
default as well as openssh-client. openssh-server is one of the other
"first" packages.
Actually, I install build-essential to get libc-dev. Then I install
linux-headers so that I can install the nVidia drivers for my display
adapter.
> Besides, it's a point of principle. Gkrelltopd is essentially one 8k .so
> file, so having it depend on 17MB of libc6-dev and linux-libc-dev is
> insane. If I want bloatware I'll run Windows.
I would suggest building gkrelltopd from source but you want to make that
impossible, too.
Are you sure less is installed by default? I ran Etch until recently and had
to install it manually. The same is true of Lenny.
Not that it's a big deal.
> Actually, I install build-essential to get libc-dev. Then I install
> linux-headers so that I can install the nVidia drivers for my display
> adapter.
Ah, that's fair enough. I don't use non-Debian stuff in "production"
machines, but I have done in "development" machines. I've actually got an
ATi card in my main machine, but not bothered with the fglrx driver, since
r300 support is coming in v6.9 of xserver-xorg-video-ati, which should be
quite soon.
>> Besides, it's a point of principle. Gkrelltopd is essentially one 8k .so
>> file, so having it depend on 17MB of libc6-dev and linux-libc-dev is
>> insane. If I want bloatware I'll run Windows.
>
> I would suggest building gkrelltopd from source but you want to make that
> impossible, too.
In a production machine, yes. All the build stuff is installed in
development machines. But like I said, it's basically a point of principle.
I can live without the plugin.
CC
[snip]
> I've actually got an ATi card in my main machine, but not bothered with the
> fglrx driver, since r300 support is coming in v6.9 of
> xserver-xorg-video-ati, which should be quite soon.
What? It's not already there? Then what have I been using...
Now, r300 RENDER acceleration – that's new.
[snip]
--
| Darren Salt | linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| Kill all extremists!
Waste not fresh tears over old griefs.
> Are you sure less is installed by default? I ran Etch until recently and
> had to install it manually. The same is true of Lenny.
README.txt:
Debian GNU/Linux 4.0 r1 "Etch" - Official i386 CD Binary-1
20070819-11:52
[duhring@einstein /cdrom/pool/main/l/less]$ ls
less_394-4_i386.deb
I damn sure never installed it as a separate package. It was already
there.
I run both Etch and Lenny setups. They all have /usr/bin/less installed
by default. Ubuntu has it installed by default as well.
'less' is Standard priority so while you could install Debian without you
would have to make a special effort.
--
John Hasler
In Debian/Sid it is a seperate package.
--
John Hasler
>> 'less' is Standard priority so while you could install Debian without you
>> would have to make a special effort.
>
> Isn't it part of debianutils?
Perhaps your news server is running slowly. About 5 1/2 hours before you
posted this I showed clearly that less is a separate package in Debian
Etch.
I meant that less is "priority: standard". The Debian priority system:
2.5 Priorities
Each package should have a priority value, which is included in the
package's control record (see Priority, Section 5.6.6). This information
is used by the Debian package management tools to separate high-priority
packages from less-important packages.
The following priority levels are recognized by the Debian package
management tools.
required
Packages which are necessary for the proper functioning of the system
(usually, this means that dpkg functionality depends on these
packages). Removing a required package may cause your system to become
totally broken and you may not even be able to use dpkg to put things
back, so only do so if you know what you are doing. Systems with only
the required packages are probably unusable, but they do have enough
functionality to allow the sysadmin to boot and install more software.
important
Important programs, including those which one would expect to find on
any Unix-like system. If the expectation is that an experienced Unix
person who found it missing would say "What on earth is going on, where
is foo?", it must be an important package.[4] Other packages without
which the system will not run well or be usable must also have priority
important. This does not include Emacs, the X Window System, TeX or any
other large applications. The important packages are just a bare
minimum of commonly-expected and necessary tools.
standard
These packages provide a reasonably small but not too limited
character-mode system. This is what will be installed by default if the
user doesn't select anything else. It doesn't include many large
applications.
optional
(In a sense everything that isn't required is optional, but that's not
what is meant here.) This is all the software that you might reasonably
want to install if you didn't know what it was and don't have
specialized requirements. This is a much larger system and includes the
X Window System, a full TeX distribution, and many applications. Note
that optional packages should not conflict with each other.
extra
This contains all packages that conflict with others with required,
important, standard or optional priorities, or are only likely to be
useful if you already know what they are or have specialized
requirements.
Packages must not depend on packages with lower priority values (excluding
build-time dependencies). In order to ensure this, the priorities of one
or more packages may need to be adjusted.
--
John Hasler