[Slackbuilds-users] Orphaning SlackBuild Scripts

[dimitar at nikov.net]

On 2026-05-04 10:10, B. Watson wrote:
> On Mon, 4 May 2026, dimitar at nikov.net wrote:
> 
>> Then this script could be removed from the repository.
>> I have no idea how this package slipped through submission form in 
>> this case.
> 
> Probably because it doesn't actually overwrite any of Slackware's
> files. It installs the module to /usr/lib(64)?/perl5/vendor_perl/, and
> the one in Slackware is installed in /usr/lib(64)?/perl5/ (without the
> vendor_perl).
> 
>> I am not playing any games, hence I don't have that package installed.
> 
> Right, you didn't know there was a conflict. Now you know... that's
> how a lot of conflicts are discovered: software works fine on your
> system, but someone else has problems with it, and it turns out to
> be because of some unrelated package. At least in this case it was
> *very* obvious what was happening.
> 
>> Also, that command check comes form the upstream.
> 
> Yes. But upstream aren't superhuman. You're packaging this thing *for
> Slackware*, which upstream probably doesn't run and has never even
> thought about.
> 
> More specifically, you're packaging it for SBo, which has a known
> conflict...
> 

Thanks for the suggestions and explanations.

However, I don’t appreciate the lecturing tone. I already said I’ll 
apply the
requested patch before handing over the package, and I’ve now done that.

I understand how software conflicts are found, so the extra commentary 
was unnecessary.

I also don’t think it matters whether the pacman game has not changed in 
10 years,
or whether only a handful of people have it installed. That is not 
relevant to the fix.
The issue was reported, I acknowledged it, and it has been patched.

Let’s leave it at that.

>> It does checks for some more package managers/OS-specific binaries
>> too. Should they be patched too?
> 
> Possibly, but probably not. It's unlikely there will ever be a binary
> called e.g. "rpm" or "dpkg" that is anything other than the actual
> rpm or dpkg (nobody's ever likely to name a game or unrelated program
> that). pacman is a special case because the Arch developers thought it
> would be cute to choose a name that already means something else...
> 
> The fact that it tries to run rpm, dpkg, etc isn't a problem. If you
> don't use these package managers, it won't find any packages installed
> by them. If you do, then it's *useful* to have hw-probe list them.
> 
> I can think of 2 good ways to patch it: either remove the whole
> "if(checkCmd("pacman"))" paragraph beginning with line 15948, or
> modify the checkCmd subroutine (starting on line 16887) so it
> removes /usr/games from the PATH. It looks like you should be
> able to change line 16900 to:
> 
>    my @Paths = grep { !m{/games} } split(/:/, $ENV{"PATH"});
> 
> ...which would remove any path including /games (including /usr/games
> and also e.g. /usr/local/games). This would allow for the (highly
> unlikely) possibility that someone's actually running Arch's pacman
> on Slackware.
> 
>> I'll do the requested patch before handing over the package.
> 
> Thanks.
> 
> I'm sorta curious if Arch (or AUR) packages up the same pacman
> game as we do, and if so what do they call the executable? pac-man,
> pacman-game, something like that... I guess I don't care enough, spent
> 10 mins searching for it, failed to find, and that's 10 minutes of my
> life I'll never get back.

As for the “10 minutes of my life I’ll never get back” comment: that was 
entirely your choice.
I didn’t ask you to look into it, so please don’t frame it as if I 
wasted your time.

Cheers,
Dimitar