yalhcru at gmail.com
Mon Oct 29 04:38:50 UTC 2018
On 10/20/18, arkadiusz at drabczyk.org <arkadiusz at drabczyk.org> wrote:
> Yes, it happens - for example parallel from misc/moreutils that I
> maintain conflicts with system/parallel. README in both contain
> appropriate information. It's really unpleasant when you find out
> that the program you've just run is not what you think it is. We
> could have some automated scripts that could analyze list of files in
> all precompiled packages and find duplicates, slackonly.com repository
> could be used for this.
I'm working on a script that does just this: parses the MANIFEST.bz2
from slackonly, and spits out a list of conflicting packages (and the
files that conflict).
It found 186 conflicts... each "conflict" is a set of 2 or more packages
that installs one or more of the same file (so if 2 packages install
the same 20 files, that's still only one conflict).
Some of these are documented in the READMEs, and some aren't. Unfortunately
there's no standard machine-friendly way to document conflicts, so I'm
having to actually read all these READMEs myself and make notes.
I'm working on whittling down the list, eliminating the documented conflicts.
For now, if anyone's interested, here's the raw list of conflicts:
Using slackonly for this isn't perfect: the MANIFEST is about 3
months old at this point, and optional stuff isn't always included in
the slackonly packages. Also MANIFEST doesn't list symlinks at all (those
are in the doinst.sh for each package) so the script doesn't check them.
However, this isn't meant to be a complaint about slackonly: I really
appreciate the hard work that goes into creating & maintaining it, and
without it, I'd have no way to even start on my conflict-finder script.
So, a big "thank you" to Panagiotis Nikolaou.
More information about the SlackBuilds-users