Code can get very complicated very quickly. As a result, often the best 'example' code is the simple stuff before a whole system evolves around the concepts. The "unfinished" projects may be more educational (and sometimes more inspiring) than monstrous creations that usually... well... almost do what we'd hoped they would.
Description of this post:
[I do think you'll like the editor function if nothing else. Try 'editor /etc/fstab --line 12' and notice that kate opens in a new window. When you close it it will not close any other files you may have open in kate.]
Creates DEB folder, which will contain the control files. Needs TREE folder containing the tree to install.
TODO. Very primitive initialization at this point, but could be made to parse RPM specs or --info output or get a stater 'template' from existing installed software or packages.
Requires: bash, dpgk, and dpgk-deb.
DEB will be linked temporarily in the binary TREE as DEBIAN during build. The reason for not simply putting it in there and working with it there is for a) visibility, and b) doing it this way keeps the tree separate from the DEBIAN files for operations such as getting the installed size, generating md5sums, etc.
Load these subroutines in bash with the command 'source deb-builder.sub'.
As you can imagine, changing from this arrangement to a gui where buttons replace the commands would not be terrifically difficult.
I prefer C/C++ anyway. :-)
But this is an experiement you might find interesting, particularly as it creates deb packages that are quite a bit smaller, if that's an issue for you.
The tighter compression may take longer to pack (done once) but they unpack very fast (done many times). As fast as tar.gz, believe it or not.
xz and/or lzma is great stuff.
Personal Explanation: I have dialup. I want to access my archives offline. The easiest way for me presently is a script-based installer/uninstaller similar to this one but with single-char commands, which is only one step away from becoming a GUI app.
But most of my tools are in RPMs, many of which I created myself but which have directory structures that won't work with kubuntu. Then need to be modified to fit the debian directory trees.
I'm porting these tools over to DEB using this setup (which is continually evolving).
Once ported, things may start really getting interesting. :-)
Especially for you internet-challenged folks like me. :-)
But is any of this "experimental" stuff really useful?
Copy the editor function above and paste it directly into a terminal, no other code is needed for this. Then type:
Then do it again. Both instances remain open. Both instances are independent (i.e., you can close either one and the other will stay open).
So is this stuff actually useful?
You decide. :-)
[Thanks for the tips from the kubuntu guys here that helped solve some of the issues involved here.]
.
Description of this post:
- An experiment to attempt to build *.deb packages with lzma compression and a very slightly more intuitive directory setup.
[I do think you'll like the editor function if nothing else. Try 'editor /etc/fstab --line 12' and notice that kate opens in a new window. When you close it it will not close any other files you may have open in kate.]
Creates DEB folder, which will contain the control files. Needs TREE folder containing the tree to install.
TODO. Very primitive initialization at this point, but could be made to parse RPM specs or --info output or get a stater 'template' from existing installed software or packages.
Requires: bash, dpgk, and dpgk-deb.
Code:
Start with a directory named TREE like so TREE ( image of root / ) +- etc (if used) +- config or inits +- usr +- whatever you have that goes here DEB ( this folder will be created, but with no control file )
Load these subroutines in bash with the command 'source deb-builder.sub'.
Code:
# file: deb-builder.sub
HERE=$PWD
#################################################
## helper subfunctions
# An editor function opens kate in a new instance
# and accepts --line ### to go to specific line.
editor()
{
cat << _eof > ~/tmp-editor.sh
#!/bin/sh
nohup kate -n \$@ > /dev/null 2>&1 &
exit 0
_eof
bash ~/tmp-editor.sh $@
rm ~/tmp-editor.sh
}
_get_md5sums()
{
local list
cd TREE
list=`find * -type f`
for i in $list; do
md5sum $i
done
cd $HERE
}
_get_blksize() # file or dir name
{
local sz=0;
let sz=`stat $1 | sed '/Size:/!d; s| Size: ||; s| .*||'`
# echo $sz
let sz=$sz/512
echo $sz
}
#################################################
## functions
get_md5sums()
{
_get_md5sums > DEB/md5sums
}
init()
{
mkdir -p DEB
echo "#!/bin/sh
set -e
" > DEB/postinst
echo "#!/bin/sh
set -e
" > DEB/postrm
chmod +x DEB/postinst
chmod +x DEB/postrm
}
has_menus()
{
cat << _eof >> DEB/postinst
# Automatically added by deb-builder
if [ "\$1" = "configure" ] && [ -x "\`which update-menus 2>/dev/null\`" ]; then
update-menus
fi
# End automatically added section
_eof
cat << _eof >> DEB/postrm
# Automatically added by deb-builder
if [ -x "\`which update-menus 2>/dev/null\`" ]; then update-menus ; fi
# End automatically added section
_eof
}
edit_control()
{
editor DEB/control
}
get_tag() # tagname filedata
{
local tagname=$1
local tagline=`echo "$2" | sed "/^$tagname/"'!'"d"`
echo "$tagline" | sed "s|$tagname: *||"
}
get_pkgname()
{
local file="$(<DEB/control)"
local pkg=`get_tag "Package" "$file"`
local ver=`get_tag "Version" "$file"`
local arch=`get_tag "Architecture" "$file"`
echo $pkg"_"$ver"_"$arch
}
# just prints to stdout, does not write to the control file
get_instsize()
{
echo "Installed-Size: $(blocksize TREE/*)"
}
get_blksize() # get size of all files under TREE
{
local total=0
local next=0
for i in `find TREE/*`; do
let next=`_get_blksize $i`
let total=$total+$next
done
echo "Installed-Size: $total"
}
build()
{
cd $HERE # to make sure
local pkgname=`get_pkgname`
cd TREE
rm -f DEBIAN
ln -s ../DEB ./DEBIAN
cd $HERE
dpkg -b TREE && mv TREE.deb $pkgname.deb || true
rm TREE/DEBIAN
}
lzma_build()
{
cd $HERE # to make sure
local pkgname=`get_pkgname`
cd TREE
# don't recurse here or you can lose your files.. I KNOW this.
rm -f DEBIAN # do this first to make sure
# now we can make the symlink
ln -s ../DEB ./DEBIAN
cd $HERE
dpkg-deb -b -Z lzma TREE && mv TREE.deb $pkgname.deb || true
rm TREE/DEBIAN
}
clean()
{
# rm -f `find * -name *~`
rm -f TREE/DEBIAN
}
help()
{
echo "
commands:
init - create DEB dir and init postinst/postrm scripts
get_md5sums - create MD5sum filename pairs
has_menus - append postinst and postrm for menus
get_instsize - (opt) get installed size before editing.
edit_control - (opt) edit the control file
get_pkgname - - show/verify name from defined fields in control file
build - - build a debian *.deb package (recommended first time)
lzma_build - - use lzma compression, smaller but takes longer
clean - - clear out temps
Note: runs in dir above TREE containing binary directory tree,
optionally needs 'kate' to edit the control file. No templates yet.
"
}
help
I prefer C/C++ anyway. :-)
But this is an experiement you might find interesting, particularly as it creates deb packages that are quite a bit smaller, if that's an issue for you.
The tighter compression may take longer to pack (done once) but they unpack very fast (done many times). As fast as tar.gz, believe it or not.
xz and/or lzma is great stuff.
Personal Explanation: I have dialup. I want to access my archives offline. The easiest way for me presently is a script-based installer/uninstaller similar to this one but with single-char commands, which is only one step away from becoming a GUI app.
But most of my tools are in RPMs, many of which I created myself but which have directory structures that won't work with kubuntu. Then need to be modified to fit the debian directory trees.
I'm porting these tools over to DEB using this setup (which is continually evolving).
Once ported, things may start really getting interesting. :-)
Especially for you internet-challenged folks like me. :-)
But is any of this "experimental" stuff really useful?
Copy the editor function above and paste it directly into a terminal, no other code is needed for this. Then type:
Code:
editor /etc/fstab --line 10
So is this stuff actually useful?
You decide. :-)
[Thanks for the tips from the kubuntu guys here that helped solve some of the issues involved here.]
.
Comment