pkgbuild: A modern, multi-architecture, package builder for Slackware Linux

tuxdev · 05-26-2010, 05:06 PM

hmm, interesting.. though of course I'm personally biased towards src2pkg and src2pkg-ng.

Darth Vader · 05-28-2010, 06:59 AM

First, I want to thank you all for suggestions and comments!

We present a new release: pkgbuild-1.0.29.tar.bz2

For properly upgrading of pkgbuild to curent release, you should use the "pkgbuild.build" script as always.

What's New?

Although the default behavior of the function "config", written by pkgbuild on install/doinst.sh is irrelevant, because it is used internal, for a better Slackware feel for those who inspect the script, we changed the default behavior on NOREPLACE. Details below.
Do not trust the downloaded files. We believe that is a good idea. Now pkgbuild will accept the downloaded files only if it can verify their checksum.
Although we are followers of the old MD5, we see nothing wrong with the ability to use an more modern SHA1. Anyway we already use OpenSSL via libCURL. Now pkgbuild accept also SHA1, SHA256 and SHA512 checksums. The instructions are similar: "Source-SHA1", "Source-SHA256" and "Source-SHA512"
The un-documented feature called "auto-formatting of the descriptions" has been improved. However, we recommend Handy-Ruler's compliance for a better control of formatting.

For those who want to use on the SlackBuilds our "config" function, used by pkgbuild for install/doinst.sh, it is shown below:

Code:

# The package installation date:
INSTALLDATE="`date '+%Y%m%d-%H%M%S'`"

config() {
  # We use the "noreplace" option by default:
  NOREPLACE=1
  if [ "$1" = "-replace" ]; then
    NOREPLACE=0
    shift 1
  fi
  NEWFILE="$1"
  OLDFILE="`dirname $NEWFILE`/`basename $NEWFILE .pkgnew`"
  # If there's no config file by that name, move it over:
  if [ ! -r $OLDFILE ]; then
    mv -f $NEWFILE $OLDFILE
  elif [ "`cat $OLDFILE | md5sum`" = "`cat $NEWFILE | md5sum`" ]; then
    # Identical files, toss the redundant copy
    rm -f $NEWFILE
  else
    # Otherwise, we leave a backup file for the admin to consider,
    # keeping the same perms as the original config file...
    if [ $NOREPLACE = 1 ]; then
      # Using the "noreplace" option:
      cp -af $OLDFILE $NEWFILE.$INSTALLDATE
      cat $NEWFILE > $NEWFILE.$INSTALLDATE
    else
      cp -af $OLDFILE $OLDFILE.pkgsave.$INSTALLDATE
      cat $NEWFILE > $OLDFILE
    fi
    # Toss the redundant copy
    rm -f $NEWFILE
  fi
}

By default, has similar Slackware behavior, but keep file permissions. This is useful, for example in rc.d scripts such as rc.httpd.

Using as the first argument "-replace", "config" will replace the old file, which will get a backup copy. Of course, it keep old file permissions on new file.

Speaking of comparing pkgbuild with src2pkg, I think it is not fair to both applications. It is like comparing apples with pears because both applications have specific skills, absent in the other. I believe that src2pkg is much easier to use for simple applications, but pkgbuild will win on complex builds, with multiple sources, patches and generation of sub-packages. In fact, src2pkg is for users, pkgbuild is for developers and contributors.

As usual, I expect your questions, suggestions and comments.

Darth Vader · 05-28-2010, 10:59 AM

Below, you have a small tutorial on how to use pkgbuild to build packages.

As I said, pkgbuild isn't a tool for novice users, but is a tool for medium to advanced users who want to build correct packages in a simple way. However, its scripting language is not ... Chinese Simplified, only RPM simplified, like one of yours said.

We decided to build the package Xdialog respecting all Slackware standards for architectures i486, i586, i686 and x86_64. Pkgbuild can help us? Let's see how.

Latest version of Xdialog is http://xdialog.free.fr/Xdialog-2.3.1.tar.bz2.

We download the source file into a directory and will extract the archive. Studying sources, we see that Xdialog uses automake tools and running "./configure --help", that has the option of using GTK2 (--with-gtk2).

Therefore, we use a template pkgspec for automake:

Code:

# PkgBuild Spec for <foo> package(s)

# Build headers

Name:     foo
Version:  1.0
Release:  1

# Sources
Source:   %{__name}-%{__version}.tar.gz

%package
# Package specific headers

%description
# The "handy ruler" below makes it easier to edit a package description. The second
# '#' on the right side marks the last column you can put a character in. It's also
# customary to make exactly 11 lines for the formatting to be correct.

#-----handy-ruler-----------------------------------------------------#
foo (cool application)

Write a nice description here.

%begin

%setup

%configure

%begin build

%{__make} %{_smp_mflags}

%begin install

%{__make} install DESTDIR=$__installdir

%files
%defattr(-,root,root,-)
/*

We change the name, version and we will complete description.

Code:

# PkgBuild Spec for <Xdialog> package(s)

# Build headers

Name:     Xdialog
Version:  2.3.1
Release:  1

# Sources
Source:   %{__name}-%{__version}.tar.bz2

%package
# Package specific headers

%description
# The "handy ruler" below makes it easier to edit a package description. The second
# '#' on the right side marks the last column you can put a character in. It's also
# customary to make exactly 11 lines for the formatting to be correct.

#-----handy-ruler-----------------------------------------------------#
Xdialog (A X11 drop in replacement for cdialog)

Xdialog is designed to be a drop in replacement for the cdialog
program. It converts any terminal based program into a program with an
X-windows interface.

The dialogs are easier to see and use and Xdialog adds even more
functionalities (help button+box, treeview, editbox, file selector,
range box, and much more).


%begin

%setup

%configure

%begin build

%{__make} %{_smp_mflags}

%begin install

%{__make} install DESTDIR=$__installdir

%files
%defattr(-,root,root,-)
/*

The question arises: what are the commands that begin with a %?

pkgbuild interpret its pkgspec, which is divided into sections, using definitions.

Some definitions are simple, eg %{__name} will be replaced with the value of the line "Name:" others are more complex, such as %configure, which will call configure with several parameters, after entering in the sources directory.

Another example. What is %{__make}? This definition will be replaced with direct path to make (ie /usr/bin/make). It is more appropriate to use these definitions to write a portable build because these paths may be different depending on the system.

Another important definition is %{_smp_mflags} which will be replaced with the auto-detected value for the make jobs. It's the $NUMJOBS's equivalent.

We will complete our definitions as follows:

Code:

# PkgBuild Spec for <Xdialog> package(s)

# Build headers

Name:     Xdialog
Version:  2.3.1
Release:  1

# Sources
Source:   %{__name}-%{__version}.tar.bz2

%package
# Package specific headers

%description
# The "handy ruler" below makes it easier to edit a package description. The second
# '#' on the right side marks the last column you can put a character in. It's also
# customary to make exactly 11 lines for the formatting to be correct.

#-----handy-ruler-----------------------------------------------------#
Xdialog (A X11 drop in replacement for cdialog)

Xdialog is designed to be a drop in replacement for the cdialog
program. It converts any terminal based program into a program with an
X-windows interface.

The dialogs are easier to see and use and Xdialog adds even more
functionalities (help button+box, treeview, editbox, file selector,
range box, and much more).


%begin

%setup

%configure --with-gtk2

%begin build

%{__make} %{_smp_mflags}

%begin install

%{__make} install DESTDIR=$__installdir

%files
%defattr(-,root,root,-)
/*

It is time to test the build. We run command:

Code:

pkgbuild Xdialog.pkgspec

If everything is correct, pkgbuild will generate in /tmp directory the package Xdialog-2.3.1-i486-1.txz and source package Xdialog-2.3.1-1.src.txz.

Inspecting the package, we will notice that the docs directory is currently in /usr/share/doc/Xdialog-2.3.1. What is wrong. He ought to be /usr/doc/Xdialog-2.3.1.

We might add --docdir=%{_docdir} to configure, but it does not support this command. We use brute force.

Code:

# PkgBuild Spec for <Xdialog> package(s)

# Build headers

Name:     Xdialog
Version:  2.3.1
Release:  1

# Sources
Source:   %{__name}-%{__version}.tar.bz2

%package
# Package specific headers

%description
# The "handy ruler" below makes it easier to edit a package description. The second
# '#' on the right side marks the last column you can put a character in. It's also
# customary to make exactly 11 lines for the formatting to be correct.

#-----handy-ruler-----------------------------------------------------#
Xdialog (A X11 drop in replacement for cdialog)

Xdialog is designed to be a drop in replacement for the cdialog
program. It converts any terminal based program into a program with an
X-windows interface.

The dialogs are easier to see and use and Xdialog adds even more
functionalities (help button+box, treeview, editbox, file selector,
range box, and much more).


%begin

%setup

%configure --with-gtk2

%begin build

%{__make} %{_smp_mflags}

%begin install

%{__make} install DESTDIR=$__installdir

# Move doc files in a properly place:
%{__mv} -f $__installdir%{_datadir}/doc $__installdir%{_prefix}

%files
%defattr(-,root,root,-)
/*

As suspected, $__installdir is the directory where pkgbuild temporary installed the package, %{_datadir} is /usr/share and %{_prefix} is /usr

The new build is perfect. It's time to add other elements.

pkgbuild know how to download the required sources. We will use this feature and we use SHA1 checksums.

We get the checksum of the source with sha1sum and we add:

Code:

# PkgBuild Spec for <Xdialog> package(s)

# Build headers

Name:     Xdialog
Version:  2.3.1
Release:  1

# Sources
Source:   http://xdialog.free.fr/%{__name}-%{__version}.tar.bz2

# Sources checksum
Source-SHA1: 292c552506633c54a28d51aa290277b7b5c0c708

%package
# Package specific headers

%description
# The "handy ruler" below makes it easier to edit a package description. The second
# '#' on the right side marks the last column you can put a character in. It's also
# customary to make exactly 11 lines for the formatting to be correct.

#-----handy-ruler-----------------------------------------------------#
Xdialog (A X11 drop in replacement for cdialog)

Xdialog is designed to be a drop in replacement for the cdialog
program. It converts any terminal based program into a program with an
X-windows interface.

The dialogs are easier to see and use and Xdialog adds even more
functionalities (help button+box, treeview, editbox, file selector,
range box, and much more).


%begin

%setup

%configure --with-gtk2

%begin build

%{__make} %{_smp_mflags}

%begin install

%{__make} install DESTDIR=$__installdir

# Move doc files in a properly place:
%{__mv} -f $__installdir%{_datadir}/doc $__installdir%{_prefix}

%files
%defattr(-,root,root,-)
/*

In our new build, pkgbuild will download the tarball and will check its checksum before extraction.

It's time to add the last element. pkgbuild known to use several build architectures. Usually is used to get the noarch packages, but we speculate this feature.

We add:

Code:

# PkgBuild Spec for <Xdialog> package(s)

# Build headers

Name:     Xdialog
Version:  2.3.1
Release:  1

%if %{!=__arch: x86_64}
BuildArch: i486 i586 i686
%endif

# Sources
Source:   http://xdialog.free.fr/%{__name}-%{__version}.tar.bz2

# Sources checksum
Source-SHA1: 292c552506633c54a28d51aa290277b7b5c0c708

%package
# Package specific headers

%description
# The "handy ruler" below makes it easier to edit a package description. The second
# '#' on the right side marks the last column you can put a character in. It's also
# customary to make exactly 11 lines for the formatting to be correct.

#-----handy-ruler-----------------------------------------------------#
Xdialog (A X11 drop in replacement for cdialog)

Xdialog is designed to be a drop in replacement for the cdialog
program. It converts any terminal based program into a program with an
X-windows interface.

The dialogs are easier to see and use and Xdialog adds even more
functionalities (help button+box, treeview, editbox, file selector,
range box, and much more).


%begin

%setup

%configure --with-gtk2

%begin build

%{__make} %{_smp_mflags}

%begin install

%{__make} install DESTDIR=$__installdir

# Move doc files in a properly place:
%{__mv} -f $__installdir%{_datadir}/doc $__installdir%{_prefix}

%files
%defattr(-,root,root,-)
/*

In our new build, pkgbuild will run package building for every architecture and we get Xdialog-2.3.1-i486-1.txz, Xdialog-2.3.1-i586-1.txz and Xdialog-2.3.1-i686-1.txz. We just need to rebuild the source package on a x86_64 machine, and we achieved also the fourth package. Voila!

PS. If you enjoyed this tutorial, the following tutorial will be called "building a package for a KDE4 application, which uses CMake". I let you to choose the application.

Darth Vader · 05-28-2010, 01:50 PM

I was notified that my example from tutorial does not meet standards because are not placed in the docs a series of files from source. These are:

ABOUT-NLS AUTHORS BUGS COPYING ChangeLog INSTALL NEWS README

The observation is correct. We have a wrong build, as can happen in real life.

How are we doing?

We can use in the %files section, files with %doc attribute and pkgbuild will copy itself these files in %{_docdir} or we can install these files manually.

Because I don't want to enter this time in the details of %files section, we will install these files manually.

Finally, we change our pkgspec as:

Code:

# PkgBuild Spec for <Xdialog> package(s)

# Build headers

Name:     Xdialog
Version:  2.3.1
Release:  1

%if %{!=__arch: x86_64}
BuildArch: i486 i586 i686
%endif

# Sources
Source:   http://xdialog.free.fr/%{__name}-%{__version}.tar.bz2

# Sources checksum
Source-SHA1: 292c552506633c54a28d51aa290277b7b5c0c708

%package
# Package specific headers

%description
# The "handy ruler" below makes it easier to edit a package description. The second
# '#' on the right side marks the last column you can put a character in. It's also
# customary to make exactly 11 lines for the formatting to be correct.

#-----handy-ruler-----------------------------------------------------#
Xdialog (A X11 drop in replacement for cdialog)

Xdialog is designed to be a drop in replacement for the cdialog
program. It converts any terminal based program into a program with an
X-windows interface.

The dialogs are easier to see and use and Xdialog adds even more
functionalities (help button+box, treeview, editbox, file selector,
range box, and much more).


%begin

%setup

%configure --with-gtk2

%begin build

%{__make} %{_smp_mflags}

%begin install

%{__make} install DESTDIR=$__installdir

# Move installed doc files in a more properly place:
%{__mkdir_p} $__installdir%{_docdir}

%{__mv} -f \
    $__installdir%{_datadir}/doc/%{__name}-%{__version} \
    $__installdir%{_docdir}/examples

%{__rm} -rf $__installdir%{_datadir}/doc

# Install the rest of doc files
%{__cp} -af \
    ABOUT-NLS AUTHORS BUGS COPYING ChangeLog INSTALL NEWS README \
    $__installdir%{_docdir}

%files
%defattr(-,root,root,-)
/*

Now we'll probably love that pkgbuild will rebuild three packages from a single command...

acummings · 05-28-2010, 02:42 PM

Quote:

Originally Posted by LuckyCyborg View Post
Yeah! I agree! I.e. my preferred SlackBuild is here:

ftp://ftp.slackware.com/pub/slackwar...kernel-headers

But, it is so wonderful that I have not managed to see him, never!
Yeah they can be elusive

Oop, next is kernel slackbuild (sym link to ____) i'm out of time to try find kenr headers slackbuild

(scroll down so as to see kern*)

ftp://slackware.mirrors.tds.net/pub/...13.1/source/a/

ftp://slackware.mirrors.tds.net/pub/...l-generic-smp/

I found the above by searching on here, the next, which is the listing

ftp://slackware.mirrors.tds.net/pub/...1/FILELIST.TXT

Alan.

Richard Cranium · 05-29-2010, 01:09 AM

Quote:

Originally Posted by Darth Vader

I believe that src2pkg is much easier to use for simple applications, but pkgbuild will win on complex builds, with multiple sources, patches and generation of sub-packages.

The src2pkg documentation contains examples of how to build with multiple sources. Using patches with src2pkg requires almost no effort; simply co-locate the patches with the source tarball and src2pkg will automatically apply them.

Since src2pkg uses bash scripts to do the work, I don't have to learn an arcane template language. Plus I won't have to download your source and try to figure out what your C code is doing in those cases where your tool is doing something unexpected.

No doubt those used to using RPM based distributions will find this tool and its template language palatable. For Slackware, it appears to be a solution looking for a problem.