[Slackbuilds-users] SBo packages conflicts?

[Didier Spaier]

Thanks Erik for your comments that show me the need of precision.

On 16/06/2016 19:58, Erik Hanson wrote:
>> 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.

Most of the conflicts of stock packages with stock packages are due to
aaa_elflibs shipping shared objects provided in other packages to allow
getting a working "minimal" system without installing the whole L series
and also ease installation. That is no (more) an issue as now Pat ships
the same versions in aaa_elflibs and the other packages anyway.

Of course there have been files shipped in several glibc-* packages
but that was never an issue as they were identical.

But that Pat takes care of avoiding harmful conflicts doesn't mean that
every SlackBuild maintainer (including myself for a very few ones) does.

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

Of course it is the duty of the maintainers and it is obvious that no
third-party package should replace a stock .h or a .so, or if it does
at least with a rationale clearly stated in the README.

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.

This proposal's goal is to help them doing that, not doing it for them.

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

Indeed: spotting the conflicts and documenting them in the README is the
duty of the maintainers, not the admins. And if I detect some I promise
to inform the maintainer and if need be to a provide patch set myself.

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

That's right, I stand corrected.

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

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.

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

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

Yes I know that you don't provide packages ;) By the way the blog post
http://alien.slackbook.org/blog/ten-years-of-slackbuilds-org/
is an interesting reading

But feeding PACKAGES.TXT (in a third party repository neither maintained
nor endorsed by SBo) from the .info files would be done by a volunteer,
possibly the repo maintainer, not by a SBo admin.  
 
>> 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.

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.

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

Yes. Just making publicly available the files that document possible
conflicts could be enough, then anyone willing to help could use that.

Best regards,
Didier