Date: Mon, 13 Aug 2018 09:09:45 -0400 From: wes Frazier <wes.frazier@members.fsf.org> To: freebsd-questions@freebsd.org Subject: Re: Resolving package conflicts (pkg set -o?) Message-ID: <d4ff970f-f37b-cbbc-4566-53bcaffd1717@members.fsf.org> In-Reply-To: <AEE94223-F999-4AE3-A887-AF100FCC5F8C@astro.gla.ac.uk> References: <03EF2AAC-B928-4B82-BB14-3AF4C009E5E5@astro.gla.ac.uk> <AEE94223-F999-4AE3-A887-AF100FCC5F8C@astro.gla.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
I am curious about this too. I am currently living with a conflict between lang/chicken and lang/mono over the 'csi' binary; and I would appreciate knowing what the proper solution is. On 08/12/18 14:12, Norman Gray wrote: > > Or (the same question more compactly expressed) is there a general > strategy for dealing with package conflicts, where two packages install > files at the same path? > > On 10 Aug 2018, at 18:10, Norman Gray wrote: > >> Greetings. >> >> When installing the 'ceph' package, I get an error: >> >> pkg: openldap-client-2.4.46 conflicts with openldap-sasl-client-2.4.46 >> (installs files into the same place). Problematic file: >> /usr/local/bin/ldapadd >> >> I'm not sure how best to resolve this. Can anyone offer advice? >> >> This happens because I've installed the openldap-sasl-client package >> in preference to openldap-client (or rather, the nss-pam-ldapd-sasl >> package installs the former rather than the latter). I take it that >> the two packages would be broadly equivalent in function from the >> point of view of dependencies. However I'm not sure what the real >> difference is between these two alternatives. >> >> One way of resolving this appears to be to use pkg set -o >> net/openldap24-client:net/openldap24-sasl-client, as mentioned in a >> UPDATING entry of 20121212 (I haven't tried this yet). >> >> However the pkg-set(8) manpage suggests this is deprecated, I can't >> find any way to reverse this if I mess up, and the discussion at >> <https://forums.freebsd.org/threads/pkg-list-origins.53689/>; suggests >> this is a rather desperate measure, in the sense that (I quote) >> 'there's no going back', and there seems to be no way to discover >> later what fixes have been applied. That is, this sounds highly >> breakable, and pretty clearly not TRTTD. >> >> Section 4 of the handbook doesn't seem to cover this situation. >> >> I can't think of where else to look. >> >> I (vaguely) imagine I could get round this by installing ceph's >> dependencies via pkg by hand, and then building net/ceph using >> portmaster. Though I see that that has an 'R-dep' on openldap-client, >> so that might just be a longer route to the same problem. >> >> I don't really want to build ceph from source. I doubt that'd be hard >> to do, but it'd be annoying to maintain (and hence errorprone). >> >> I can't be the first to have this type of problem, so I expect I'm >> missing something pretty obvious. >> >> Best wishes, >> >> Norman >> >> >> -- >> Norman Gray : https://nxg.me.uk >> SUPA School of Physics and Astronomy, University of Glasgow, UK >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d4ff970f-f37b-cbbc-4566-53bcaffd1717>