On Sat, Feb 25, 2017 at 04:14:11PM +0100, Andrew Shadura wrote: > On 25/02/17 08:35, Niels Thykier wrote: > > I got one question about the "Breaks". Why Breaks and why a versioned > > breaks rather than an unconditional Conflicts? AFAICT, pkgconf attempts > > to be an "mutually exclusive alternative" to pkg-config (a la exim vs. > > postfix).
The reason for me proposing breaks instead of conflicts was that unpacking both packages can actually work (due to the use of diversions), whereas running both maintainer scripts ends up in unpredictable chaos (both managing the same set of symlinks). We know that conflicts are harder to solve by apt and thus - generally - have a slight preference on using breaks. > Hmm, honestly, I'm not sure what's better in this case. In #842529, > Helmut mentioned Breaks, so I just went with that. As it is now, pkgconf > is still co-installable with earlier versions of pkg-config (diversions > are still in place), but the symlinks make it not possible to have both > pkg-config 0.29-1 and pkgconf installed (and that's not really needed > anymore as I added the versioned Provides). The version restriction initially confused me, but the explanation makes sense to me. > If you think Conflicts is more appropriate, I may add change that in the > upload to unstable. > > Helmut, what's your opinion, by the way? I don't think that it matters much in this case. I imagine that breaks vs replaces is not going to make a big difference for apt here. Whether to use the weakest form (versioned breaks) or a strong form (conflicts) is up to you. Looking at the experimental binary package however, I note that I fail to find a diversion for pkg-config-dpkghook and its hook-config. Thus the experimental package would actually need a conflicts relation now. See e.g.: | # dpkg -B --unpack pkgconf_0.9.12-2_amd64.deb | dpkg: considering deconfiguration of pkg-config, which would be broken by installation of pkgconf ... | dpkg: yes, will deconfigure pkg-config (broken by pkgconf) | (Reading database ... 9798 files and directories currently installed.) | Preparing to unpack pkgconf_0.9.12-2_amd64.deb ... | De-configuring pkg-config (0.29-4) ... | Adding 'diversion of /usr/bin/pkg-config to /usr/bin/pkg-config.real by pkgconf' | Adding 'diversion of /usr/share/aclocal/pkg.m4 to /usr/share/aclocal/pkg.real.m4 by pkgconf' | Adding 'diversion of /usr/share/man/man1/pkg-config.1.gz to /usr/share/man/man1/pkg-config.real.1.gz by pkgconf' | Adding 'diversion of /usr/share/pkg-config-crosswrapper to /usr/share/pkg-config-crosswrapper.real by pkgconf' | Unpacking pkgconf (0.9.12-2) ... | dpkg: error processing archive pkgconf_0.9.12-2_amd64.deb (--unpack): | trying to overwrite '/etc/dpkg/dpkg.cfg.d/pkg-config-hook-config', which is also in package pkg-config 0.29-4 | Errors were encountered while processing: | pkgconf_0.9.12-2_amd64.deb | # So I consider the experimental package rc buggy and propose either renaming the conflicting files or adding a conflicts relation. Since neither /usr/share/pkg-config-crosswrapper nor /etc/dpkg/dpkg.cfg.d/pkg-config-hook-config are part of the pkg-config API, I'd just rename both to avoid the need for diversions here. Even when using conflicts, conffiles will not go away and reusing the hook-config file from pkg-config can result in a mess of its own. So I actually recommend doing the renaming (s/pkg-config/pkgconf/) in any case (even when adding conflicts). If you end up using conflicts, all the other diversions can go away as well. Helmut
