[Slackbuilds-users] sip conflicts with kdeaddon

Alan Hicks alan at lizella.net
Fri Mar 7 14:18:42 EST 2008


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.

-- 
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20080307/259fba33/attachment.bin>


More information about the Slackbuilds-users mailing list