[Slackbuilds-users] nonstandard build scripts

Pierre Cazenave pwcazenave at gmail.com
Wed Aug 10 09:41:20 UTC 2011



On 09/08/2011 10:22, B Watson wrote:
> On 8/9/11, Erik Hanson<erik at slackbuilds.org>  wrote:
>> I have a bit of a two-pronged question. Is there really that much code
>> in drumkit2pkg that it can't be done in the SlackBuild itself?
>
> Well, there's code in drumkit2pkg that's irrelevant to the SlackBuild: it
> can wget the tarballs, and it can alter the drumkit.xml so that all the
> hi-hat drums are in the same mute group (so that, if you've got an open
> hi-hat hit, followed by a closed one, the open hit won't keep ringing out
> over the closed hit. This is *essential* for realistic-sounding drums,
> but I don't call this code from hydrogen-drumkits.SlackBuild).

I'd probably submit a stripped down version of drumkit2pkg that does 
only what's necessary to build the package in the way closest to a 
traditional SlackBuild. That is to say it doesn't try to get the sources 
itself, rather it expects them to be in the current directory. I don't 
see any problem with editing config files such that they make for a more 
useable package (something which I've done before and no-one seems to 
have minded (or noticed!)).

> The script actually tries to find the documentation within the
> .h2drumkit tarball and place it in /usr/doc.

I don't think this is non-standard; I always move documentation to where 
Slackware has traditionally kept it.

> It looks for demo-songs
> within the tarball, places them where they belong (different dir from the
> drumkits). It specifically looks for a drumkit.xml file (and refuses to
> makepkg if it doesn't find it).

If this drumkit.xml is crucial, then this makes sense. If it's not, 
perhaps you can just spit out an error. My tesseract SlackBuild [0] does 
something similar.

[0] 
http://slackbuilds.org/slackbuilds/13.37/graphics/tesseract/tesseract.SlackBuild

 > It tries to handle incorrectly-packaged
> drumkits (that don't contain a top-level directory within the tarball). If
> you don't give it a slack-desc, it generates one... It basically tries
> to be more generic than a regular SlackBuild would be.

I think that the most useful thing might be for you to post the 
drumkit2pkg script somewhere (as an email or on pastebin or something) 
and then we'll all know where we stand :) Someone might even edit it as 
they think fits SBo's policy.

Pierre


>
>> It looks like these h2drumkit files are just tarballs. What all do you
>> have to do (besides unpack and place the files in the correct location)
>> that, again, can't be done in the SlackBuild?
>
> Nothing, I just don't want to rewrite the thing, is what this boils
> down to... especially if I'm ever going to submit more drumkit packages
> (in which case I'd have multiple copies of it, possibly different from
> each other).
>
> Eh, at this point, this thread now contains more text than the script
> contains actual code, maybe I should have just STFU and submitted it.
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - http://slackbuilds.org/faq/
>


More information about the SlackBuilds-users mailing list