On 2013/01/09 17:01, Vadim Zhukov wrote: > 2013/1/9 Stuart Henderson <[email protected]>: > > There's a conflict between net/ktorrent and the libktorrent port in > > openbsd-wip. > > Actually, no. libktorrent was split out of KTorrent upstream a while > ago as a separate distpackage, and corresponds to net/ktorrent-kde4 > port only. And net/libktorrent does not conflict with net/ktorrent > except this nit: > > * net/libktorrent installs ${PREFIX}/lib/libktorrent.so.X.Y; > * net/ktorrent installs ${PREFIX}/lib/libktorrent.so and > ${PREFIX}/lib/libktorrent-${VERSION}.so (${VERSION} is KTorrent's > version itself).
ah - I missed that net/ktorrent doesn't have an so version - that should be okay then. > Even more, due to kdelibs-* conflict (they still could not be > installed at the same time) we could be sure that KDE3 and KDE4 apps > will not mix anyway for now. I do not want to manage conflicts of > KDE3<->KDE4 packages now because upstream packages gets split and > stuff in them gets moved here and there all over the time, forcing > re-doing un-conflict work eventually. Unconflicting KDE 3 and 4 is on > my TODO list, but not now. For things where the same PKGNAME stem is used (e.g. foo-1.0 and foo-2.0) the packages will be handled as conflicting automatically, there's only a problem where things move between packages. Can be skipped for now but it would need to be done when things are linked to the build - check-conflicts run against a set of all packages from both versions will track these down. > > disk/CPU isn't a reason not to link to the build, however approaching > > an OpenBSD release with two versions of popular KDE-based apps and > > no clear way to distinguish them when pkg_add asks "Ambiguous: choose > > package for digikam" *is* a reason not to link them ;) > > Hm-m-m, this path definitely should be investigated. I'm curious again > about adding name suffixes for KDE4-land packages, e.g.: > "digikam-kde4-2.9.0.tgz" or even "digikam-2.9.0-kde4.tgz" instead of > current "digikam-2.9.0.tgz"... the suffix after the version number (i.e. digikam-2.9.0-kde4) should only be used for a FLAVOR, digikam-kde4 (with the appropriate conflict markers so that this conflicts with digikam-*, and digikam conflicts with digikam-kde4) should work - alternatively kde4-digikam, which shows up nicely in a directory listing.
