I am trying to install the latest Opera web browser on my Lucid x86_64
desktop computer. Currently Opera 9.20 is installed, which I did a long
time ago by downloading the .deb file and installing it with gDebi or
dpkg.

This evening I downloaded the latest .deb (11.61) and tried to install
it. I got an error message that, although not very clear, led me to
believe that it could not be installed without first removing 9.20. I
also found instructions for adding the opera repository, which I did,
and now Opera 11.61 is listed in Synaptic. But trying to install it with
Synaptic results in the same error message.

I can launch Opera 9.20 and it runs fine. But Opera 9.20 is not listed
in Synaptic. "Aptitude show opera" says there is no such package.
"Aptitude remove opera" says no packages are to be removed.

WTH? How do I get rid of 9.20? How is it that I can launch and run a
program that is not installed on the computer?

Jason,

You will probably have to use dpkg -l to find the exact Opera package
name and dpkg -r %packagename% to remove it.

Joseph Hume
F1 for HELP

PLUG mailing list
PLUG*******/mailman/listinfo/plug

Have you tried sudo dpkg -i packagename.deb ?

--
Benjamin Kerensa                          "I am what I am because
Team Lead, Ubuntu Oregon                  of who we all are." - Ubuntu
bkerensa*******

1. Uninstall  http://ubuntuforums.org/showthread.php?t=1042091

2. Install via sudo dpkg -i packagename.deb or if newer is available via
repo then sudo apt-get install packagename

--
Benjamin Kerensa                          "I am what I am because
Team Lead, Ubuntu Oregon                  of who we all are." - Ubuntu
bkerensa*******

The command "apt-cache pkgnames | grep <pkgname>" command will list any
packages in the apt-cache that have that name.

e.g.

root@mc-sidux:~# apt-cache pkgnames | grep chrome
google-chrome-unstable
xserver-xorg-video-openchrome
google-chrome-beta
xserver-xorg-video-openchrome-dbg
google-chrome-stable

If by chance Opera isn't listed try using the "locate" or "mlocate" command.

e.g.

root@mc-sidux:~# locate opera
/lib/modules/2.6.32-2.slh.4-sidux-686/kernel/drivers/media/dvb/dvb-usb/dvb-usb-opera.ko
/usr/include/c++/4.4/parallel/set_operations.h
/usr/lib/python2.5/lib-dynload/operator.so
/usr/share/icons/oxygen/16x16/actions/irc-operator.png
/usr/share/icons/oxygen/16x16/actions/irc-remove-operator.png

You may need to update  the locate database with the command "updatedb &"

If you find Opera directories and files you will have to remove them
manually.

You can also try apt-get install -f Opera and see if that will fix broken
package dependencies. Which sometimes happens in situations like these.

Good luck!

aptitude remebers which packages you deliberately installed and which have
been automatically installed to satisfy dependencies. Upon removal of a
package aptitude will remove those automatically installed packages to keep
your system tidy. apt-get isn't that smart.

aptitude will quickly become an indispensable tool once you use different
repositories with different versions of a package. Imagine you are working
with backports.org or inofficial repositories like debian-multimedia.org.
Then aptitude will show (at the bottom of the details page of a certain
package) the available version number and allow you to select one.
If you get into a situation where programs conflict due to such usage of
inofficial repositories you will see a "Broken: ..." display on the top.
You can type l~b (limit / flag / broken) and just get a list of packages
that conflict with each other. Makes it much easier to resolve the conflict
manually.

Benjamin Kerensa <bkerensa*******> dijo:

That thread assumes you know the name of the package. Unable to
continue.

I don't have a problem with installing; I just need to uninstall the
old one before the install will go.

Benjamin Kerensa <bkerensa*******> dijo:

Don't have the package name. That's the problem.

Joseph Hume <joseph*******> dijo:

That's what I needed, the -l switch. I did

    sudo dpkg -l |grep opera

And it listed the package as opera-static. WTH? What were those Opera
people thinking? "Static"? Who would have guessed that? And note that
Synaptic never listed opera-static. At first it listed nothing, then
after enabling the special Opera repository it listed Opera 11.61. Very
strange.

Anyway, once I knew the name of the package "sudo dpkg -r opera-static"
got rid of it. And then "sudo aptitude install opera" found version
11.61 in the repository and added it.

All is peaceful again in Lucid-land. Thanks for the hint. :)

you need to uninstall in (roughly) the same way that you originally
installed. since you didn't install opera via apt, you should not expect
apt to know about it or help you uninstall it.

-wes

And for further fun-
The "static" most likely means that the package is statically linked to the
required libraries, instead of relying on the ones installed on the system
(which would be dynamically linked), which could sometimes lead to version
conflicts.

Just my $0.02 :)

Glad it worked out

----------
Matt M.
LinuxKnight

"There are two basic types of installations, static and shared:

*Static version*: Opera has the Qt library built in. It is a larger
download, and it does not use anti aliased fonts on menus or the file
chooser, and uses aliasing in the browser window and most other interface
elements.

*Shared version*: Opera uses the Qt installation on your system. It
integrates with the system, using whatever anti aliasing setting you have
for other Qt applications.

Which is better? Probably the Shared version. Try the other one if you run
into installation problems."

wes <plug*******> dijo:

Explain why I should not expect apt to know about all packages
installed on the computer. You see, in my silly way I assumed that
whenever a package was installed, regardless of what package manager
installed it, it would then be listed in a central database file of
installed apps. Thus, all package managers would know about it. The
whole operating system would know about it. Menu editors would know
about it. Even (gasp!) the user of the computer would be able to find
out about it. There would be no confusion and fragmentation of function.

I don't doubt the truth of what you say. I just think that a package
manager that is not aware of all packages installed on the system is a
fail.

I don't know if I can, with any degree of sanity. If there were only one
package manager, this wouldn't be a problem. Different package managers
exist for a reason - no comment on whether this is a GOOD reason or not.

You see, in my silly way I assumed that

This is a fictional item.

Thus, all package managers would know about it.

Package managers maintain their own lists of things they've installed. it
wouldn't really be reasonable to expect one package manager to stay up to
date on all the latest from all the other managers. And then there's the
problem of applications installed without the use of a package manager.
Package managers are different for the same reason that different
distributions of Linux are different.

The

The "operating system" doesn't know or care about any packages that are
installed. It's not like there is a central "registry" where all the info
about everything is stored. This is why package managers were invented to
begin with.

Even (gasp!) the user of the computer would be able to find

I agree, the user is a very hard problem to solve.

There would be no confusion and fragmentation of function.

Welcome to real life.

Maybe it is, maybe it isn't. Maybe you expect too much.

-wes

According to http://www.debian.org/doc/manuals/debian-faq/ch-pkgtools.en.[..]  <snip>
'It is important to understand that the higher level package management
tools such as aptitude or dselect rely on apt which, itself, relies on
dpkg to manage the packages in the system.' </snip>

If I read this right, any software package 'installed' via aptitude /
apt should be listed by dpkg.  At least on a Debian based machine.

I did qualify 'installed' because there are several programs and
packages you simply unzip in a folder of choice and execute. Mozilla
Firefox and Thunderbird on Debian Lenny / Squeeze / Wheezy / SID being
two prime examples of unzip and execute.  Because they are not handled
through a 'package manager' nobody would know of their existence.

Joseph Hume
F1 for HELP

PLUG mailing list
PLUG*******/mailman/listinfo/plug

Because the package manager is only going to know about the software you
installed with it as there's a difference when software
is installed from source (not a .deb or .rpm *package*) in which the user
may be required to sort out dependencies and conflicts verses
letting the package manager logic sort it out.

The level and complexity of the logic, the richness of features and keeping
the integrity of installed software intact are the reasons
package managers exist. Before then everything was installed / removed by
hand. How fun it must have been to be a Sys Admin then.

There is however a way to create a virtual package when installing from
source which would create a place holder in the package system inventory
which would allow you to search the package system for source installed
software and to also keep track of all the dependencies.

http://www.debian.org/doc/manuals/apt-howto/ch-helpers.en.ht[..]

I have to take exception with previous statements about a lack of central
package tracking in debian-based distros. This is completely false. The
/var/lib/dpkg directory is used exactly for that purpose. This way all of
the apt-based (which as previously pointed out is all dpkg-based anyway)
can query any installed package and do stuff with it.

To prove it to yourself strace some dpkg or apt commands.
strace -o /tmp/dpkg.out dpkg -l >/dev/null && less /tmp/dpkg.out
strace -o /tmp/dpkg.out dpkg --get-selections >/dev/null && less
/tmp/dpkg.out
strace -o /tmp/dpkg.out apt-cache search chrome >/dev/null && less
/tmp/dpkg.out

You'll notice that with any of these commands that they open() and read()
/var/lib/dpkg/status among others files.

Cheers,

bd