The Testing Area :: March extensions

Quote

If so, can anyone point me toward an easy example so I can fix the problems.

Read the steps on the wiki. There's a page for each kind of MyDSL extension.
http://damnsmalllinux.org/wiki/index.php/Creating_MyDSL_Extensions

I again want to pick the nit I started about the php script. That's not the kind of thing that even requires compilation (move it to /opt/phpcaptchascript/nameofphpcaptchascript), and is something anyone using php can already find and stick in ~/ or wherever it's needed or desired for testing or use. Is making it into a MyDSL tar.gz really necessary or even desirable?

Quote (lucky13 @ Mar. 29 2008,16:53)

Read the steps on the wiki. There's a page for each kind of MyDSL extension.
http://damnsmalllinux.org/wiki/index.php/Creating_MyDSL_Extensions

Been there, done that. That's where I found:

Quote

There is also the fact that a lot of people don't know how or just don't want to have to compile source,or maybe they don't have the tools to do so.

Since I am one of those to which the above applies, I was trying to find some simple progs that the following would apply to:

Quote

Building a green extension can sometimes be as simple as packing up a pre-compiled binary with the appropriate ownership.

Apparantly, I made a mistake. OK, get over it. I seem to recall a rather famous person who suggested, "Let he who is without sin cast the first stone."

Nit picking is never helpful, nor is name calling, uttering slurs et cetera and so on. Posting tools that make the task more accessible to everyone _is_ helpful. Answering the question asked is also helpful.

So, once again, I recall reading about forcing a program to run in /opt when it wants to run somewhere else. I think it involved writing a "wrapper script" to package up with the application. If I had an example of one, I'd probably be able to figure out how to modify it for any app I upload.

===> Can anyone point me to an example? <===

This is kind of off-topic for the extensions thread, but you could perhaps try this as an example of how to build and test an extension:

1. Create your workspace:

Code Sample

$ sudo mkdir /usr/src
$ sudo chown dsl /usr/src
$ chgrp staff /usr/src

2. Download a source tarball and unpack it to /usr/src - lets say grub-0.97.tar.gz for the sake of an example.

3. Prepare things to compile:

Code Sample

$ mydsl-load /path-to-file/compile-3.3.5.uci
$ export CPPFLAGS=-I/opt/compile-3.3.5/include

4. Compile:

Code Sample

$ cd /usr/src/grub-0.97
$ ./configure --prefix=/opt/grub-0.97
$ make
[open a terminal window as root]
# cd /usr/src/grub-0.97
# make install

5. Navigate to /opt/grub-0.97 and delete stuff that is not needed - info files, man files, doc files, etc. Then strip the binaries, libs, etc:

Code Sample

$ sudo strip --strip-unneeded /opt/grub-0.97/bin/*
$ sudo strip --strip-unneeded /opt/grub-0.97/sbin/*
$ sudo strip -g /opt/grub-0.97/lib/* [not required in this example]

6. Create links for the binaries to /opt/bin and save them for the extension to use:

Code Sample

$ ls /opt/grub-0.97/bin/* > /path-to-file/files_user
$ ls /opt/grub-0.97/sbin/* >> /path-to-file/files_user
$ beaver /path-to-file/files_user
[edit to read /opt/bin rather than /opt/grub-0.97/bin, etc and save]
$ sudo ln -s /opt/grub-0.97/bin/* /opt/bin
$ sudo ln -s /opt/grub-0.97/sbin/* /opt/bin
$ sudo tar -T /path-to-file/files_user --no-recursion -zcvf /opt/grub-0.97/user.tar.gz

7. Make the extension:

Code Sample

$ cd /opt
$ sudo mkisofs -R -hide-rr-moved grub-0.97/ | create_compressed_fs - 65536 > /tmp/grub-0.97.uci

8. Tidy up and load the extension:

Code Sample

$ sudo rm -r /opt/grub-0.97
$ mydsl-load /tmp/grub-0.97.uci

9. Test the extension by making a boot floppy:

Code Sample

$ fdformat /dev/fd0H1440
$ mke2fs /dev/fd0
$ sudo mount -t ext2 /dev/fd0 /mnt/floppy
$ grub-install --root-directory=/mnt/floppy fd0
$ sudo umount /mnt/floppy

Apologies for sticking this in this thread, hope it helps.

Quote

Apologies for sticking this in this thread, hope it helps.

This thread will be pretty much at an end in a day or two (it's the end of the month), so I don't think it matters now.

Quote

I was trying to find some simple progs that the following would apply to:

Quote

Building a green extension can sometimes be as simple as packing up a pre-compiled binary with the appropriate ownership.

Key words there are *sometimes* and *a*, meaning that you can't expect to do it with just any application, and it was referring to a single binary file, which can be run from /opt/myapp/bin rather than the /usr/bin directory into which it would normally be installed. That still doesn't imply that you can do it with *any* single-file application. Some programs just expect to be installed into a specific location, and won't run otherwise. There's nothing that can be done in that case other than stick with a dsl or unc package, or compile the application from source.

Quote

I recall reading about forcing a program to run in /opt when it wants to run somewhere else. I think it involved writing a "wrapper script" to package up with the application. If I had an example of one, I'd probably be able to figure out how to modify it for any app I upload.

Most wrappers I've seen include either setting the LD_LIBRARY_PATH variable to add the /opt/something/lib directory, changing to the application directory, or both. There are many possible issues that may require wrapping, though. Please don't expect that you can have one or two examples that you can modify for any occasion. Your best chance of building proper application packages is to become comfortable wih your knowledge of the file system, and learn the basics of shell scripting.
http://linux.die.net/man/7/hier
http://www.pathname.com/fhs/
http://www.tldp.org/LDP/Bash-Beginners-Guide/html/index.html
http://www.tldp.org/LDP/abs/html/index.html

Quote

, I was trying to find some simple progs that the following would apply to:

Quote
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.

Quote

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
/opt/captchascript/
/opt/captchascript/something.php

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-2.0.0.13/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:
http://www.lamarelle.org/firefox....tar.bz2
And the update for Seamonkey gtk1 version is here:
http://releases.mozilla.org/pub.....tar.gz

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):
http://www.seamonkey-project.org/releases/#1.1.9
http://www.lamarelle.org/mo-zi-lla/mozilla.php#fx

Next Page...
original here.