[Slackbuilds-users] SBo packages conflicts?

[Didier Spaier]

Hi to all and Petar,

On 16/06/2016 16:30, Petar Petrov wrote:
> Hi to all.
> 
> What is your opinion and is SlackBuilds.org going to do something in
> regards to this:
> 
> http://www.linuxquestions.org/questions/slackware-14/slackpkg-add-on-for-sbo-4175581768/page2.html#post5558622
> 
> bye
> 
> Petar

Please see the message forwarded below.

I sent it  Tuesday but for some reason it didn't go through

@Admins: what happens? I asked to Rob yesterday, no answer so far.
Maybe my IP is banned by slackbuilds.org, but why?

@Petar: if you don't see this message on the list abut 10 minutes
after having received it, would you be kind enough to forward it
to the list for me? TIA.

Regards,
Didier


-------- Forwarded Message --------
Subject: Suggested method to better document the conflicts between packages.
Date: Tue, 14 Jun 2016 23:16:21 +0200
From: Didier Spaier <didier at slint.fr>
To: SlackBuilds.org Users List <slackbuilds-users at slackbuilds.org>

This is a proposal intended as a request for comments.

The goal is to avoid that installing a package built from a SlackBuild
overrides files installed by another one.

Why? Because unless replaced and replacing files be identical, this can
prevent the already installed software and those that depend on it to
work properly.

Manually spot such conflicts is a daunting task, as that needs to check
each package against thousands of other ones.

But David has written scripts that automatize finding the collisions and
summarizing them per tuple of packages, see the post #21 in:
http://www.linuxquestions.org/questions/slackware-14/slackpkg-add-on-for-sbo-4175581768/

I found the results very interesting, so I suggest to build on that
to spot and document the conflicts:
_ at least in the README files of the conflicting packages,
_ and also in a new "CONFLICTS:" field of <package>.info.

The latter would then allow package tools to parse this information,
either from the <package>.info file or through the PACKAGES.TXT file.
Some package tools can already make use of the CONFLICTS info in
PACKAGES.TXT and it won't be difficult to copy from the former to the
latter.

So here is my proposal (after adaptation if need be of the scripts
written by David as a proof of concept).

The list of collisions and tuples (packages included in Slackware and
SlackBuilds hosted @ slackbuilds.org) would be updated after the 14.2
release. Then these list would be made available to all SlackBuild
maintainers (maybe after sort of the tuples per maintainer), who could:
_ check which of their packages are among the tuples if not yet sorted,
_ grep collisions to see which files would be overwritten,
_ assess the collisions: some are harmless others not,
_ in case of harmful collisions, insert a warning in the README and/or
  feed <package>.info with the name(s) of the conflicting packages, 
_ possibly consult with the maintainers of the conflicting SlackBuilds,
  about how to avoid collisions if possible, else inform the users in a
  consistent way.

I didn't give much thought about how to deal with updates of Slackware
packages and SlackBuilds after the release but this should be addressed.

Thanks for having read this long post and in advance for your thoughts.
Cheers, Didier