[Slackbuilds-users] sip conflicts with kdeaddon

[ciol]

Alan Hicks wrote:
> Robby Workman wrote:
>>> Slackbuilds from SBO belong to this tradition (in my opinion), but I 
>>> do not want to speak about this again.
>>
>> I would argue that the distinction comes in when the software is
>> packaged and installed _as_a_package_; packaged software goes to
>> /usr (or /opt as appropriate), while non-packaged software goes to
>> /usr/local (or elsewhere as deemed appropriate by the sysadmin).
>> However, I agree that this has already been hashed out, and our
>> decision stands as is, so there's no need to drag it out again.
> 
> I'm with Robby on this one and personally, I'm tired of it being 
> discussed as well.  It's a very minor issue; I really don't understand 
> why it sometimes turns into a holy war.  If you don't want packages 
> compiled from SBo scripts in /usr, just edit the friggin' PREFIX 
> variable and you're done.
> 
>>> Anyway, why not create a /usr/slackbuilds-conflicts for these kind of 
>>> conflicting packages?
> 
> I've thought about that myself, or rather something like a 
> /usr/lib/sbo-conflicts, but that's an ugly kludge if I've ever seen one. 
> I'm just not confident that it wouldn't cause more problems than it fixes.
> 
>> This sort of information belongs in the README.
>> I'll have to defer judgment on what is *most* appropriate here to
>> those individuals more familiar with the affected software, but I'm
>> curious as to whether packaging sip in /opt/sip (assuming the relevant
>> environment variables are set) would work out okay, or if the included
>> sip stuff in kdebindings would conflict.  Maybe there are some other
>> concerns too...
> 
> In general, when we've had a conflicting package, we simply noted such 
> in the README (see dropbear in 12.0 for an example).  In this case 
> though, I'm really not certain what the best course of action really 
> is.  Noting it in the README and including the script in the repo might 
> cause problems for users down the road, and subsequently tarnish our 
> image.  On the other hand, turning down a script that some one submits 
> with the sort of humility and knowledge that Aleksandar showed when the 
> problem was first reported isn't exactly the kind of thing I'd like to 
> do either.
> 
> FTR, I'm for noting the conflict in the README, perhaps in ALL CAPS or 
> something so it stands out.  Also, the script itself could warn.  
> Something like...
> 
> cat EOF
> This script creates a package that is known to conflict with the 
> kdebindings package included in Slackware.  While it has been tested, we 
> cannot vouch that problems will not occur with other software which uses 
> sip.  If you believe you have encountered such a problem, please remove 
> this package and re-install kdebindings, then try again before filing a 
> bug report to the maintainer or the mailing list.  Press ENTER to continue:
> EOF
> read NOTHING
> 
> 
> Of course this isn't a perfect solution either, and I'm as open to 
> suggestions here as anyone.
> 

I suggest to add variables, and to write an explanation in the README:

python configure.py -b $PREFIX/bin \
                     -d $PREFIX/lib/python2.5/site-packages \
                     -e $PREFIX/include/python2.5 \
                     -v $PREFIX/share/sip

with $PREFIX by default to /usr or /opt/sip or /usr/foobar, whatever you 
want. The user will have the choice.