sbbuilder development. (was: Packaging mini-tool for 6.0 (and maybe 5.9))

[kidd]

Sbbuilder (SlackBuild Builder) is a small perl script for automating the
generation of the directory structure and the SlackBuild necessary for
making packages compliant with the VectorLinux repository.
It was made with three goals. The first one is to give facilities for
making a standard repository. The script would reproduce the same
structure for every package making more easy the maintenance and the
realization of automated tasks. The second is to give a tool for packagers
in order to make your life a bit easier and improve your productivity.
Developers and enthusiastics that build many packages will find it (we hope)
useful. Finally, we hope it will be part of a bigger app developed for porting
an existing VL repository to different architectures.
First the installation. We are using Template-Toolkit, you need to install it
in your system. It is very easy:

Code: [Select]

cpan Template
If you install it as root the resource will be available for all users, if you
are planning to use sbbuilder as your regular user you can install TT with your
regular account. You will be prompted with a few questions, defaults are OK.
If you never used cpan before, it's the perl modules repository. It ask for
your location the first time in order to use the nearest mirror. We are going
to include TT in the default installation in the future.

Now we are ready to take a look into Sbbuilder.  Install it with

Code: [Select]

slapt-get --install sbbuilder
Its usage is pretty straight forward. Two parameters are required:

Code: [Select]

ssbuilder --package=<name_of_the_package> --version=<version>
This will build the directories and place a SlackBuild with the package name
and version information.
The directory tree is like this:

AppName
|
`-- Version Number
        |
        `-- src
             |
             `-- AppName.SlackBuild

The SlackBuild will be filed with AppName and Version where is pertinent.
A number of optional arguments can be used in a way that it allows to
generate the whole SlackBuild without need of extra editing.

--user Your packager ID. If not used it will look for the
VL_PACKAGER environment variable (you can define it in your shell
startup script, tipically ~/.bashrc). If that var is not set the
script will use the current username returned by `whoami`.

--build Define a build number (as in 1vl60). If not defined the
script will default to 1.

--link This is a new variable in the SlackBuild template. You can
define a URL to the tar.gz or tar.bz2. The SlackBuild will download
the sources using wget if no sources are found in the working dir.
This variable will be useful if a repackaging is needed.

--type Different kinds of sources are available in the OpenSource
world . We need to configure the sources properly.It defaults to usual configure
The possible values of this argument are:

* perl Use this to build perl modules and general perl
applications. Perl packages need a special configuration for
working and this option provides it.

* python Obviously for building python apps . This option
writes the classic python setup.py lines in the proper place.

* noarch This will replace the ARCH (tipically i586)value with
"noarch". In this way users know that they can use your package
in any architecture.

* cmake For modern and cool developers that are using cmake
instead the old lady GNU Autoconf.

--configure_options Pass extra options for the configure script (or cmake)
with this option.

--ldflags Define extra ldflags for the actual compiling process.

--help You wont believe it, it shows a short help message.

--manual Well, shows the manual.

As you note, if all the options are used you get a fully working SlackBuild with a
oneliner (I admit it, a long one), and if you place a slack-desk file in the same
dir of the SlackBuild, you may not need extra editing. Of course this is for
applications in general, many will need extra tweaking of the SlackBuild.
The new template written by uelsk8s provides a special place for the application of
patches, and you have the classic "extra tweakings" section after the configure
lines. It's very important to use the indicated places for doing this stuff, so the
script will be easy to understand for other packagers and also automated tasks can
be made (grep is powerful! ).

Enjoy and as always, suggestions, patches, fixes and insults are welcome.

uelsk8,rbistolfi,kidd

[uelsk8s]

I just wanted to say, that I cant take the credit for writing the Template.
IT was written by lots of people in the packagers forum and bits found throughout the internet, I merely composed it

[M0E-lnx]

Not having any luck with the CPAN modules here.

so I can't test

[toothandnail]

I've never used cpan before ( and didn't read the instructions until it failed the first time, naturally). However, once I did read the directions, was able to get cpan configured and (presumably) got the templates module loaded.

Only tried it a couple of times for pretty standard builds, but it has worked for both of them (the libpcap and wireshark builds were both configured using sbbuilder). Looks good. I will be trying some Python based stuff next, since that is something I always have difficulty building conventional SlackBuilds for.

Very nice. Thanks, a very useful tool.

paul.

[MikeCindi]

I couldn't find the sbbuilder package but cpan setup okay as far as I could tell. Can't go any further for now...

[kidd]

MikeCindi,

Thanks for testing    sbbuilder is in the testing repo of 5.9 and 6.0 aswell.

Make sure you have it enabled.

Keep questions/suggestions coming!

[MikeCindi]

Okay, I'll try again later as I still can't find it (perhaps the repo mirror needs to "refresh").

It's later...this is what I get:

Code: [Select]

root:# slapt-get --install sbbuilder
Reading Package Lists... Done
The following NEW packages will be installed:
  sbbuilder
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 4.0kB of archives.
After unpacking 30.0kB of additional disk space will be used.
1/1 Get http://vectorlinux.osuosl.org/veclinux-6.0/packages/ sbbuilder 0.4.8-noarch-1vl60 [4.0kB]...Failed to download: HTTP response code said error
I'm getting this with a lot of packages from the 6.0 repo the last two days.

[toothandnail]

I got the same error when trying to reinstall (after I reinstalled beta 2.2 in place of beta 2.4). Fortunately, I had the older version in the local cache, so I was able to manually install it.

Waiting for the update...

paul.

[MikeCindi]

Okay, now with rc1 the sbbuild seems to be working as it should. Now the question is am I working as I should on building packages. I've been using checkinstall for long enough that using makepkg is not coming back to me as I would want it to. Thus after getting into the source dir my process should be:

Code: [Select]

sbbuilder --package=<name_of_the_package> --version=<version> ...
./configure && make
su
make install DESTDIR=/myworkarea
cd /myworkarea
makepkg <name_of_the_package>-<version>-<build>-1vl60.tlz
Perhaps I will grow to like this over time but

Code: [Select]

./configure && make
su
checkinstall -L
seems to be much simpler. 

[uelsk8s]

actually for the simple apps it would be just

Code: [Select]

ssbuilder --package=<name_of_the_package> --version=<version> ...
sh <name_of_the_package>.SlackBuild

[MikeCindi]

Thank you; sounds easy enough. I've obviously gotten lazy with making packages and not kept up...

[MikeCindi]

actually for the simple apps it would be just

This is TOO easy. I guess I've mostly just made "simple" packages as only a few have required me to pass args to configure. As I read through the SlackBuild script it does everything that I would do (and much more) and should make it easy for anyone to create standardized packages of the "simple apps". With a little reading and tweaking of the script the more complex apps (to build) should also be easy enough.

I realize what I've just written is the intent of kidd's original post but somehow it didn't register with me. Thanks again for making VL so user-friendly.

Mike

[kidd]

It's great you liked it.

It's a pretty simple script, in fact, the perl part has nearly no logic at all, but with a wise use of Template Toolkit we've managed to write a fairly user-friendly tool.

Now there's no excuse to not give packages to community and repos

Cheers,

Kidd

[toothandnail]

I've hit a bit of a problem with sbbuilder's handling of info files. Also have a suggestion for an addition...

I've just built a package which by default places info files in /usr/share/info. While the routine in the sbbuilder-generated script looks as though it should work, it leaves the directory in place, so the info files don't get moved and don't get gzipped. I'm still trying to work out why the routine doesn't work....

I also have a suggestion for an improvement in handling info files. A lot of packages that include info files also include a 'dir' file. As things stand at the moment, that file will be placed in /usr/info and then gzipped along with the info file.  It will overwrite a normal /usr/info/dir file. Looking at the package list from 6.0 RC4, there are two packages that come with /usr/info/dir.gz files (aspell and texi2html).

I would like to suggest that the handling of info files be expanded to search for and delete any dir files during the build, and if info files are processed during the build, a doinst.sh be generated to update /usr/info/dir during the install. I normally remove and rebuild the completely, since I don't know what state the existing /usr/info/dir file may be in. For instance, in the texinfo package I built, I create this doinst.sh:

Code: [Select]

doinst() {
# Install ddrescue info file.
    cd usr/info
if [ -f dir ]; then
    rm dir
    fi
if [ -f dir.gz ]; then
    rm dir.gz
    fi
for i in *.info.gz
        do
        install-info $i dir
    done
}
Adding something like that would make sure that any info files in a package would be applied, and would also ensure that /usr/info/dir was correctly updated.

paul.

[rbistolfi]

Thank you very much for your input Paul. Uelsk8s addressed the issue and a new version (0.4.11.3) was uploaded.
Kidd implemented a new feature. Now, if no --package and --version options are used, sbbuilder will attempt to get them from the url passed to --link. This will work only with source tarballs named with the classic scheme (name)-(version).tar* though. The error is not handled yet, I forgot about it. If sbbuilder cant guess version and name, it will spit some perl garbage, we will implement a nice message and a clean exit for the next one