[Slackbuilds-users] SBo packages conflicts?

[Erik Hanson]

On Fri, 17 Jun 2016 12:20:11 +0200
Didier Spaier <didier at slint.fr> wrote:

> The difficulty is to spot the conflicts between thousands of packages
> that can be built from SlackBuilds provided by SBo and then take care
> of the "true positives", even if in the end there are not many (that
> I don't know).

Something I hadn't considered when writing my original reply, and I
think significantly changes my view on things, is that it's not
practical at all for anyone to have all SBo-derived packages installed
in order to check against them. A solution would be a FILES.TXT, but
I consider this difficult to the point of impracticality. Some scripts
have build-time options that could change the contents of the output
package. The same is true for optional dependencies.

Someone could build every possible combination of every SlackBuild in
the repo, to generate a list of files, but I fear for that persons
sanity. :)

Consider how many permutations of ffmpeg there are. The 14.1 script has
33 options, and 36 optional dependencies. Some of those may have
options/optional deps as well.

Note that I'm not saying ffmpeg dumps out a different set of files in
all those cases, for all I know it's the same every time. It serves
as a good example though, showing that we can't predict what every
package looks like on every persons system.

> It is maybe less obvious to maintainers that conflicts between two
> packages both built from stuff from @ SBo should (or at least could)
> be taken care as well.

Indeed, it wasn't even obvious to me until now. I had written from the
perspective of checking against stock packages, in which case
everything I said is still true.

> But in the few cases where there are real conflicts that can't be
> avoided modifying the scripts, would a .info that includes a
> CONFLICTS: line be accepted? Of course mentioning the conflicts in
> the README would stay mandatory.

This information has to come from somewhere, it doesn't currently
exist. As I expressed above, I don't have confidence in the ability to
generate it.

> > By and large, there aren't many scripts that generate conflicting
> > packages. Not nearly enough to justify adding a CONFLICTS line to
> > the .info files. (n.b. this is in reference to packages and not
> > files within packages.)  
> 
> I would really know for sure how many scripts generate conflicting
> packages (real conflicts, not false positive) ;)

I imagine grep'ing the READMEs for 'conflicts' give a close
approximation.

> Yes. I already stated, I just suggest that they could (even if it is
> optional) take care of also of conflicts with files coming from
> packages built from SBo scripts.

The best we can hope for, I think, is when someone notices conflicts
they report it to the respective maintainers or this list.


-- 
Erik