Joined: Feb. 2007
||Posted: Mar. 30 2008,12:21
|, I was trying to find some simple progs that the following would apply to:|
Building a green extension can sometimes be as simple as packing up a pre-compiled binary with the appropriate ownership.
My nitpicking point is, your captcha script wasn't a pre-compiled binary. It's a php script. Scripts are much more portable than binaries -- you call scripts with a binary or another script from wherever you want or need it. Binaries generally aren't portable because of the various and sundry linking between them and libraries, etc.
|Nit picking is never helpful, nor is name calling, uttering slurs et cetera and so on.|
I was trying to be constructive with my nitpicking -- such as asking if scripts are really appropriate for MyDSL since users probably don't want to search through /opt for every possible thing that could be submitted as a tar.gz. BTW, who called anyone names or uttered slurs?
You don't need a wrapper script to kludge a php script into /opt. All you'd need to do for that is put the script where you want it in /opt (e.g., /opt/phpcaptcha) and then make a tarball of it. When you enter the command, you'll get output like the lines beneath it in this example (first I made the directory and for this I just touched "something.php" in it):
|Code Sample |
|% tar cvfz ./captchascript.tar.gz /opt/captchascript/ |
tar: Removing leading `/' from member names
Voila, I have a file called captchascript.tar.gz in my pwd (present working directory) that conforms to MyDSL, but could include a menu entry (another reason I dislike the idea of scripts like this is invoking it from a menu -- why?). I could mydsl-load that and it would install it in /opt just as it was. That's all there is to it -- no wrappers, just a tarball with a file in a directory in /opt.
The standard examples of binaries that work well for relocation to /opt are Open Office and mozilla products like Firefox, Seamonkey, etc. These are most often distributed as binary packages that install everything they need in one portable, nested directory (e.g., /usr/local/openoffice-1.2.5 is the default for that particular version but a change of its install script can put it anywhere else including /opt). If it's all already contained in one nested directory like that, it's probably a very good candidate for tar.gz/uci extension.
Many other binaries won't work for tar.gz/uci without being recompiled because they're internally linked with paths across standard directories (e.g,, a DEB for xmms will install xmms in /usr/bin and its libs in /usr/lib/xmms and not /opt/xmms/lib/xmms, so that binary requires its libs to be in a specific place which makes relocation ridiculous). If it's not all nested in the same directory, you'll need to compile with prefix=/opt/application-name. Also, some things that you try to compile as tar.gz/uci won't like being in /opt for some reason. That's when you'd try a wrapper to kludge it together.
If you want to try making some tar.gzs and ucis, Mozilla just made some major security updates to their products this week. I was going to submit gtk1 versions later today (after my Longhorns beat Memphis) because it's been a while since the versions in MyDSL have been updated. I'll let you do it if you want -- these are pretty easy because all their stuff goes into one nested directory. It's not very difficult at all. You can untar in /opt and they'll be set up right there -- no need to relocate them, pretty straightforward. If you do make any changes, it might be to rename (mv) from firefox/seamonkey to firefox-126.96.36.199/seamonkey-1.1.9 (respectively) in case users want to use multiple versions (if UCI, though, users can unmount one version and then load another and use the same mountpoint). Use the steps 6+ Juanito posted to add a user.tar.gz for links and menu entries and then make UCI extensions for each. Let me know if you're going to mess with these.
The "Bon Echo" gtk1 version is here:
And the update for Seamonkey gtk1 version is here:
I don't think anyone here is out to give you a hard time. We just want to insure that MyDSL extensions work and don't cause any trouble. I think we all appreciate your desire to contribute to MyDSL, which is why (speaking for myself) I tried to help with the first round you submitted.
EDIT: Here are the relevant pages for the links above. I haven't read the build info for each so I don't know if there are any issues for DSL (I've been using both in Vector without issue since they were released this past week but that's with all up-to-date libs):
"It felt kind of like having a pitbull terrier on my rear end."
-- meo (copyright(c)2008, all rights reserved)