[Slackbuilds-users] sip conflicts with kdeaddon

[Robby Workman]

ciol wrote:
> Aleksandar B. Samardzic wrote:
>> On Fri, Mar 7, 2008 at 12:24 PM, ciol <ciol13 at gmail.com> wrote:
>>> A solution would be to install sip in another location.
>>>
>>>  Here is what I did:
>>>
>>>  python configure.py -b /user/local/bin \
>>>                      -d /user/local/lib/python2.5/site-packages \
>>>                      -e /user/local/include/python2.5 \
>>>                      -v /user/local/share/sip
>>>
>>>  Then I needed:
>>>  export PYTHONPATH=/usr/local/lib/python2.5/site-packages/
>>>
>>>  I am really not an expert of python or qt, therefore there is maybe a
>>>  better solution.
>>>
>>>  I also installed pyqt4 this way, not sure if it was necessary.
>>
>> There is a slight issue with conformance this way - having files from
>> a package installed into /usr/local would be against LSB, and also,
>> more importantly, against long standing Unix tradition to only have
>> software compiled locally, from the source, installed there...
> 
> 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.


> Anyway, why not create a /usr/slackbuilds-conflicts for these kind of 
> conflicting packages?


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

-RW