Grokbase Groups Perl qa April 2013

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.

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.
It's not mentioned in the dependencies section.

pkgsrc has CONFLICTS=Some-Name-[0-9]* essentially a regex.
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".

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".

It doesn't shine much new light on the issue except that package
management systems agree, you need a conflict tag.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 6 of 7 | next ›
Discussion Overview
groupqa @
postedApr 15, '13 at 4:56p
activeApr 18, '13 at 8:26a



site design / logo © 2017 Grokbase