[Slackbuilds-users] sip conflicts with kdeaddon
rworkman at slackbuilds.org
Fri Mar 7 14:04:05 EST 2008
> 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
More information about the Slackbuilds-users