Re: Strange CONFLICTS definitions render pkgin full-upgrade impossible

["Aleksej Lebedev" <root%zta.lk@localhost>]

On Fri, May 21, 2021, at 08:37, nia wrote:
> On Thu, May 20, 2021 at 05:03:08PM +0200, Aleksej Lebedev wrote:
> > However I checked if there are other packages with that kind of definition left in pkgsrc and I found some:
> > 
> > $ find textproc -name Makefile | xargs grep ^CONFL | grep ruby
> > textproc/ruby-bluecloth/Makefile:CONFLICTS+=	ruby[1-9][0-9]-bluecloth-[0-9]*
> > textproc/ruby-rttool/Makefile:CONFLICTS+=	ruby[1-9][0-9]-rttool-*
> > textproc/ruby-amrita/Makefile:CONFLICTS+=	ruby[1-9][0-9]-amrita-*
> > textproc/ruby-maruku/Makefile:CONFLICTS+=	ruby[1-9][0-9]-maruku-*
> > 
> > We happen not to use those but I am quite sure they will cause the same problem with pkgin upgrade.
> > 
> > My question: is it just a mistake or is there some kind of good indent behind those CONFLICTS defs?
> 
> These packages are self-conflicting between different ruby
> versions (e.g. ruby26-bluecloth and ruby25-bluecloth can't be
> installed at once) because they install an unprefixed/suffixed
> binary to bin/.

Thanks, this makes sense. However the package should not conflict with itself built against the same version of ruby.
Which means that either CONFLICTS should be fixed (I don't see how) or, alternatively, pkgin can be patched so that it ignore that kind of conflict.

It seems to me that the second option is more viable.

> 
> This is pretty bad practice, there should be a separate package
> for the binary if the ruby library is independentaly useful,
> otherwise they shouldn't be versioned.

I happen to solve that kind of conflict in some python packages by using ALTERNATIVES for binaries.
But even if all those packages are fixed, it still makes sense to allow for that packages and therefore CONFLICTS statements of that kind should be considered OK. Which brings me back to the problem with pkgin upgrade.
I guess this indeed should be fixed on the side of pkgin.

I'll try to prepare a patch for pkgin then.
--
Aleksej Lebedev