Ubuntu
ubuntu-meta package

Bug #22335
Comment #3

Comment 3 for bug 22335

Revision history for this message

Scott James Remnant (Canonical) (canonical-scott) wrote on 2005-09-23:

Ok, I'm starting to get a bit tired of this ... I'm going to schedule a BOF at
UbuntuBelowZero to explain to you guys carefully, lovingly and with a baseball
bat exactly what Conflicts and Replaces *mean* in an attempt to stop you using
them like this!

Seriously guys, we use "dpkg" and not "rpm" -- so trying to use these headers as
you would in RPM is going to do almost exactly the wrong thing in every
circumstance.

Now shut up, sit down, and listen.

In the dpkg world, only one package may own a given file at a time. There is no
way to have two packages installed which own the same file, one of them has to
own it. The Conflicts and Replaces headers are *ONLY* used for resolving this
problem in the case where "foo" and "bar" both provide the same file.

If both foo and bar provide /some-file; and you install foo, and then install
bar (or the other way around) you will get an error at unpack time that bar is
trying to overwrite /some-file when it is owned by foo.

The Replaces header means that bar *MAY* overwrite files owned by foo, and that
after doing so the file is owned by bar. If bar Replaces foo, and you install
bar (when foo is installed) it will succeed; and any files overwritten are now
owned by bar.

THIS HEADER DOES NOT MEAN THAT bar IS A REPLACEMENT FOR foo; DPKG IS NOT RPM!
If you prefer, think of this header as "Overwrites".

The reason this header is dangerous to use is that once bar has overwritten a
file owned by foo, bar now owns the file and not foo. If bar is removed, SO IS
THE FILE! Removing bar can damage foo. It is primarily used to split packages
where the package that used to own the file can Depend on the package that now
owns the file (and Replaces the parent).

The Conflicts header means that bar *MAY NOT* overwrite files owned by foo, even
if the user tries to force it with --force-overwrite. This header means that
bar is known to have the same files as foo, and that the files are *different*
in some way (usually two applications providing /usr/bin/filename which are
different). Installing bar will damage foo. The installation of bar will fail
unless foo has been removed first.

THIS HEADER DOES NOT FORCE AN UPGRADE OR PACKAGE CHANGE!
It simply states that foo and bar provide the same filename on disk, and that
the user should be prevented from trying to force the issue as they'll only
damage their system.

In particular, this header is only used at unpack time on the package being
installed. If bar Conflicts foo, and you install foo and then bar, the
installation of bar will be refused. However if you install bar, and then
install foo, that's fine because foo doesn't Conflict bar. For this reason
Conflicts nearly always come in pairs, both foo and bar should Conflict each other.

And this is the reason this header is dangerous, once foo and bar Conflict each
other, there's no way to install one without removing the other first and no way
for that to be processed by an upgrade engine. Once done, you can't swap
packages around. It's most commonly used with a virtual package provided by
both (see below), and generally discouraged in favour of using diverts and
alternatives to allow swapping of the packages.

Combining fields is special, and can be used to start to provide the kind of
effects you're actually after.

If bar BOTH Conflicts AND Replaces foo, it means that bar is a wholesale
replacement for foo and the two packages may be swapped (but only one installed
at a time). foo should ALSO Conflict and Replace bar. If you read the headers
using the above knowledge, you will realise that this means that bar can freely
overwrite the files of foo, and once done force the removal of any that are left.

This is almost always used with a virtual package, and not with particular
package names, for example:

Provides: x-window-system-screensaver
Conflicts: x-window-system-screensaver
Replaces: x-window-system-screensaver

If both xscreensaver and gnome-screensaver were to do this, it would mean that
you could only have one of the two installed at the same time. THIS SHOULD
STILL ONLY BE USED WHERE THEY SHARE COMMON FILES. The canonical example is
mail-transport-agent which all install "/usr/bin/sendmail".

THERE IS NO HEADER IN DPKG FOR DECLARING THAT A PACKAGE IS BROKEN BY ANOTHER, OR
SIMPLY JUST BROKEN. This long-discussed header is called "Breaks" and has yet
to be implemented.

Now that I hope you understand, please remove the conflict from
gnome-screensaver; it does not contain any of the same files as xscreensaver:

$ comm -12 <(dpkg-deb -c gnome-screensaver_0.0.13-0ubuntu4_i386.deb | sed
"s/.*\.\///" | sort) <(dpkg-deb -c xscreensaver_4.21-4ubuntu14_i386.deb| sed
"s/.*\.\///" | sort)
etc/
etc/pam.d/
usr/
usr/bin/
usr/share/
usr/share/applications/
usr/share/doc/
usr/share/pixmaps/

(those are all directories)

This conflict does not have the intent you expect, and will cause problems for
us in dapper when we'll be unable to resolve upgrade issues due to it.

Seriously guys, we use "dpkg" and not "rpm" -- so trying to use these headers as
you would in RPM is going to do almost exactly the wrong thing in every
circumstance.

Now shut up, sit down, and listen.

In the dpkg world, only one package may own a given file at a time.  There is no
way to have two packages installed which own the same file, one of them has to
own it.  The Conflicts and Replaces headers are *ONLY* used for resolving this
problem in the case where "foo" and "bar" both provide the same file.

The Replaces header means that bar *MAY* overwrite files owned by foo, and that
after doing so the file is owned by bar.  If bar Replaces foo, and you install
bar (when foo is installed) it will succeed; and any files overwritten are now
owned by bar.

THIS HEADER DOES NOT MEAN THAT bar IS A REPLACEMENT FOR foo; DPKG IS NOT RPM!
If you prefer, think of this header as "Overwrites".

The reason this header is dangerous to use is that once bar has overwritten a
file owned by foo, bar now owns the file and not foo.  If bar is removed, SO IS
THE FILE!  Removing bar can damage foo.  It is primarily used to split packages
where the package that used to own the file can Depend on the package that now
owns the file (and Replaces the parent).

The Conflicts header means that bar *MAY NOT* overwrite files owned by foo, even
if the user tries to force it with --force-overwrite.  This header means that
bar is known to have the same files as foo, and that the files are *different*
in some way (usually two applications providing /usr/bin/filename which are
different).  Installing bar will damage foo.  The installation of bar will fail
unless foo has been removed first.

In particular, this header is only used at unpack time on the package being
installed.  If bar Conflicts foo, and you install foo and then bar, the
installation of bar will be refused.  However if you install bar, and then
install foo, that's fine because foo doesn't Conflict bar.  For this reason
Conflicts nearly always come in pairs, both foo and bar should Conflict each other.

And this is the reason this header is dangerous, once foo and bar Conflict each
other, there's no way to install one without removing the other first and no way
for that to be processed by an upgrade engine.  Once done, you can't swap
packages around.  It's most commonly used with a virtual package provided by
both (see below), and generally discouraged in favour of using diverts and
alternatives to allow swapping of the packages.

Combining fields is special, and can be used to start to provide the kind of
effects you're actually after.

If bar BOTH Conflicts AND Replaces foo, it means that bar is a wholesale
replacement for foo and the two packages may be swapped (but only one installed
at a time).  foo should ALSO Conflict and Replace bar.  If you read the headers
using the above knowledge, you will realise that this means that bar can freely
overwrite the files of foo, and once done force the removal of any that are left.