Tiny Core Linux

General TC => Programming & Scripting - Unofficial => Topic started by: soapboxcicero on January 01, 2011, 06:35:05 PM

Title: auto extension package script
Post by: soapboxcicero on January 01, 2011, 06:35:05 PM
There's a lot of drudgery involved with making extensions. The submitqc script is nice but I wanted the computer to do it for me instead of telling me I did it wrong. There are a lot of improvements (especially in the error handling department) that could be made to this so hit me with all the ideas and fixes you have.

You still have to set everything up but it makes the tcz, the md5 sum, the list file and tars it all up and bcrypts it for you. (It also fills in the date and file size in the .info file).

This script takes one parameter, the name of the directory that is the 'root' of your package. It assumes that the .info file is in pwd, if it exits--otherwise it creates a skeleton and opens it in your editor. All files are created in pwd.

Note that while it does not explicitly handle any .dep files if one with the proper name is in pwd it will impicitly be bundled up with everything else. Given an empty directory, a .dep and an .info this should generate a metaextension though I have not tested that use-case.

Code: [Select]
#!/bin/sh

PN=$(basename $1)

if ! tce-load -i squashfs-tools-4.x >/dev/null
then
echo Requires squashfs-tools-4.x >&2
exit 1
fi

CDATE=$(date +%Y/%m/%d)

echo \* Poking files

if test -d $1/usr/local/tce.installed
then
chmod -R 755 $1/usr/local/tce.installed
chown -R root:staff $1/usr/local/tce.installed
fi

echo \* Creating .tcz
rm -f ${PN}.tcz
if ! mksquashfs $1 ${PN}.tcz -no-progress >/dev/null
then
echo Creation of .tcz failed >&2
exit 1
fi

SZ=$(du -h ${PN}.tcz | awk '{ print $1 }')

echo \* Creating .md5.txt
md5sum ${PN}.tcz > ${PN}.tcz.md5.txt

echo \* Creating .list
find $1 -not -type d | sed 's#'$1'##;s@^/@@' > ${PN}.tcz.list

if test -e ${PN}.tcz.info
then
echo \* Updating .info
<${PN}.tcz.info sed '
s@^Size:\([ \t]*\).*$@Size:\1 x1x=X*X=x1x '$SZ'@
s@^Current:\([ \t]*\).*$@Current:\1 x1x=X*X=x1x '$CDATE'@
s/ x1x=X\*X=x1x //g
' >${PN}.tcz.info.2
sync
mv ${PN}.tcz.info.2 ${PN}.tcz.info
else
echo \* Creating .info
>${PN}.tcz.info cat <<!
Title: ${PN}.tcz
Description: xTODOx
Version: xTODOx
Author: xTODOx
Original-site: xTODOx
Copying-policy: xTODOx
Size: $SZ
Extension_by: xTODOx
Comments: xTODOx
Change-log: xTODOx
Current: $CDATE
!
$EDITOR ${PN}.tcz.info
fi

if grep xTODOx ${PN}.tcz.info >/dev/null
then
echo Cannot continue until all fields have been filled in >&2
exit 1
fi

echo \* creating encrypted archive, password tinycore
if ! tar zcf ${PN}.tar.gz ${PN}.tcz*
then
echo Failed to create tarball >&2
exit 1
fi

if ! yes tinycore | bcrypt ${PN}.tar.gz 2>/dev/null
then
echo Failed to encrypt tarball >&2
exit 1
fi

(updated code)
Title: Re: auto extension package script
Post by: Jakob Bysewski on January 02, 2011, 04:56:12 AM
Welcome to the forums!

Nice work, but have you seen a similar but a bit more sophisticated Makefile based script I posted some days ago int this thread:
http://forum.tinycorelinux.net/index.php?topic=8247.0

I don't want to devalue your work, maybe we could even work together on this?
Title: Re: auto extension package script
Post by: soapboxcicero on January 02, 2011, 11:50:08 AM
I don't want to devalue your work either but I don't like the idea of conflating building something from source with packaging an extension.

There is often a one to one correspondence between a program with a makefile and an extension but there are a lot of edge cases: no makefile, custom (ie, non-autoconf) configure script, exotic build systems such as jam or scons.

Moreover, there is a need to build nonsoftware extensions like doc extensions, locale extensions, and metaextensions.

That's why I wrote my script to worry only about taking specified data and turning it into an extension and not worrying about how that data got there or where it came from. However, after saying all of that it is still extremely common to have a correspondence between an extension and an autoconf/automake'd tarball so I do think your script is very useful.

I'm open to working together on this. I'd love to make this script bullet proof, but I don't see much point in working the extension part of it into a Makefile. There are a lot of parts that could be skipped if they exist but there's no good way to make sure they're out of sync that'd be quicker than just redoing it all which doesn't take that much time or effort. And though technically make could parallelize large sections of the process, I'd think the overhead of that parallelizing would likely make the process slower, and even if it doesn't the speed up would be infinitesimal in all but the case of mksquashfs which could be easily &'d and wait'd for if that's the case.

Perhaps you could have your Makefile invoke my script for the extension building part so that it's all in one place, useful on its own, but easily augmented by your Makefile in the case that you want to just build, package, and deploy?
Title: Re: auto extension package script
Post by: Jakob Bysewski on January 02, 2011, 01:10:07 PM
I understand your point and I'll think about it.

One think I like about looking at other solutions to a similar problem is, that you always can learn something from them - so thank you!

As an example, you used:
Code: [Select]
echo 'tinycore
tinycore' | bcrypt ...
While I could not get bcrypt to be fed the password by echo, so my solution to this is:
Code: [Select]
yes tinycore | bcrypt ...
(yes answers all input promts by 'y'<Enter> or the given parameter)
Title: Re: auto extension package script
Post by: hiro on January 02, 2011, 02:30:13 PM
Cool, this is cleaner than my personal script.
Title: Re: auto extension package script
Post by: soapboxcicero on January 02, 2011, 05:53:58 PM
Didn't know yes was included in busybox. That simplifies the line a little so I'll make the switch. Noticed an error in the .list generation line that made it so the script only worked if you were in dirname $1. Fixed.

I also added some checks to make it die reasonably if something goes awry.

New version is attached but the changes weren't so numerous to be worth putting in a code block.

edit: figured out how to change attachment on main post so I sync'd it