[Slackbuilds-users] sip conflicts with kdeaddon
ciol13 at gmail.com
Fri Mar 7 14:38:06 EST 2008
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:
> 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 \
with $PREFIX by default to /usr or /opt/sip or /usr/foobar, whatever you
want. The user will have the choice.
More information about the Slackbuilds-users