[Slackbuilds-users] SBo packages conflicts?

[Erik Hanson]

On Thu, 16 Jun 2016 18:16:16 +0200
Didier Spaier <didier at slint.fr> wrote:

Since this is intended as RFC, these are my comments and not meant to
be me setting anything in stone.

> 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 noticed a significant number of lines that are stock packages
conflicting with stock packages. These are not the concern of SBo, but
suggest to me, at least, that most conflicts are probably not very
important. As such, my initial concern is minimal. Important conflicts,
like incompatible .h files being replaced, need to be dealt with.

> 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,

This is how it's supposed to already happen. If it's not true for some
scripts, their README files need to be updated. If anyone on the list
is willing to do the work and provide a patch set, that would be
appreciated. I'm guessing no admins really have the time for this. I
don't want to further burden the few that are working hard on getting
us ready for 14.2.

The idea of doing it after 14.2 is a bit moot, this can be done at any
time, and should be done sooner rather than later.

> _ and also in a new "CONFLICTS:" field of <package>.info.

This will probably not happen. Conflicts such as wxPython and wxGTK
should have that info in the README already. As for individual files
conflicting, like docs or headers, that should be dealt with in some
way such as removing or renaming the files before generating the
package. If that's not possible (it breaks the package), then a mention
in the README is necessary.

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

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

We don't provide any PACKAGES.TXT file, since, you know, we don't
provide packages. :) If you meant SLACKBUILDS.TXT, there are no
CONFLICTS lines in said file.

> 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

Internally, we have a post-check script that checks for conflicts with
files that already exist in a full install. I'm not sure if every admin
is using it, or if it's broken, or this is the result of using git more
than we did in the past. Especially right now, while we're focusing on
14.2, "updates" aren't running the way they usually would for the stable
branch. The usual way being to run the post-check during approval.

Ultimately though, maintainers should be making sure this doesn't
happen.

> 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

Thanks for looking into it initially. Again, if anyone is willing to
step up and provide patches, that would probably be best. Some
maintainers are inactive (or busy, or uninterested) and simply creating
a list of them, and/or contacting them, may not prove entirely fruitful.


-- 
Erik