Re: Comments regarding pink-pony_1.3.1-2_i386.changes
On 15/09/13 18:33, Miriam Ruiz wrote:
> 2013/9/15 Markus Koschany <apo@gambaru.de>:
>> I had a brief look at pink-pony's control file and I think it is more
>> reasonable to use Breaks and Replaces instead of just Conflicts, so that
>> the package manager can find a better solution for an upgrade or
>> installation.
>
> I understand Breaks, but why Replaces?
tl;dr: "because about half the time, dpkg will fail to upgrade it if you
don't". :-)
"Replaces" is short for "replaces some files from", or to put it another
way, "may overwrite files from". If pink-pony-data Replaces: pink-pony
(<< x.y.z), that means that if p-p is currently at a version < x.y.z,
dpkg has permission to overwrite files previously owned by p-p (and mark
them as owned by p-p-d) when it installs p-p-d. Normally, dpkg will
report an error and stop the installation rather than allowing files to
be overwritten.
Breaks/Replaces means p-p-d may overwrite files from p-p, but when it
does, p-p will enter a broken "deconfigured" state in which its files
are unpacked but it isn't necessarily usable. Subsequently upgrading p-p
fixes that temporary broken state, leading to this upgrade path:
p-p (old)
p-p-d (new); p-p (old, deconfigured because p-p-d Breaks it)
p-p-d (new); p-p (new, configured again)
This dependency path is also valid, but I don't think there's a way to
tell apt/dpkg that is *must* follow it (apart from Conflicts, which is a
bigger hammer than Breaks/Replaces), so it won't always choose this route:
p-p (old)
p-p (new, deconfigured because its Depends are unsatisfied)
p-p-d (new); p-p (new, configured again)
Conflicts is stronger than Breaks, so it puts more constraints on
apt/dpkg: it requires p-p to be uninstalled completely (so its files are
deleted altogether) rather than just deconfigured. The fewer options
apt/dpkg has, the more likely it is that an upgrade from stable to
testing, or oldstable to stable, gets into an impossible situation and
can't be completed: that's why use of Pre-Depends and Conflicts is
discouraged. (Technically, Conflicts is like a negative Pre-Depends,
whereas Breaks is like a negative Depends.)
As far as I can see, Replaces with neither Conflicts nor Breaks is only
appropriate if you split a package, and files in the new small package
are a fully-backwards-compatible replacement for files in the old large
package (e.g. identical files, as seen in openarena-081-maps replacing
part of openarena-data). It's also probably only *useful* if you split
out a separate source package (like those openarena packages). If you're
splitting binary packages but keeping them sharing a source package, as
you are here, the p-p package's version number will have gone up anyway
(even if there's no new upstream version), so it's probably going to be
upgraded in the same apt transaction that installs the new p-p-d
package, and there's no real benefit in allowing it to be kept at the
old version.
Regards,
S
Reply to: