On 4/15/13 7:06 PM, Jens Rehsack wrote: > On 15.04.13 18:56, Michael G. Schwern wrote: >> TL;DR version... >> IMO we only need to clarify what "conflicts" means and what actions CPAN >> tools should take. >> >> We talked in the Consensus Dome about the need for and meaning of the >> "conflicts" relationship in the CPAN::Meta::Spec. >> https://metacpan.org/module/CPAN::Meta::Spec#Prereq-Spec >> >> IIRC the conclusion was... >> * We need it. >> * It's not clear what it means. (I don't recall what the confusion was) > > The difference between "A conflicts with B op VER" and "A breaks B op > VER" and "A superflous B".
IIRC those meant... "A conflict B" is A and B cannot be on the machine at the same time. For example, they're both http servers and need the same port. I can't think of an example where CPAN has needed that for modules. "A breaks B" is if A is installed B will break. This is what we need on CPAN for things like Test::Builder breaks Test::Class < 0.39. "A superfluous B" is if A is installed B is no longer necessary. Usually called "obsoletes". This is mostly useful if you rename a package, though I'd rather that was made more explicit in the meta data. Most of the use cases I can think of are better handled by the installed modules database and CPAN distribution meta data. >> * Let's see what Debian does. > > Or MacPorts, HomeBrew or pkgsrc :P Whatever packaging system I may actually use, I go to Debian first because they extensively document this sort of thing, both the meanings and the rationales. Let's have a look at what the others do... MacPorts has a conflicts tag, but I can't find the docs. The only mention of conflicts I can find in the MacPorts manual is "variant X conflicts Y" but there's no explanation what that means. https://www.macports.org/guide/chunked/reference.variants.html It's not mentioned in the dependencies section. https://www.macports.org/guide/chunked/reference.dependencies.html pkgsrc has CONFLICTS=Some-Name-[0-9]* essentially a regex. http://www.netbsd.org/docs/pkgsrc/fixes.html#conflicts All they say is the "package may conflict with other packages a user might already have installed on his system" Homebrew has an undocumented "conflicts_with". https://github.com/mxcl/homebrew/blob/master/Library/Homebrew/formula.rb rpm has "Conflicts" and "BuildConflicts" which is only defined as "where one package conflicts with a capability provided by another" which isn't very useful. rpm also has "Obsoletes" "where one package obsoletes capabilities provided by another, usually used when a package changes name and the new package obsoletes the old name". https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch-advanced-packaging.html It doesn't shine much new light on the issue except that package management systems agree, you need a conflict tag.
