LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 05-25-2010, 01:51 PM   #1
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 621

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


We are pleased to present one of our new creations: pkgbuild, a tool written in standard C++, using libCURL, ZLib, BZip2 and libLZMA (part of XZ).

It is a modern Slackware packages builder, network-transparent, multi-architecture, designed to greatly simplify the creation of a package, automatically executing the required post processing.

What does it do?
  • Recognize and build packages for the following architectures: i386, i486, i586, i686, x86_64, IA64, IA32e, s390, s390x, sparc and sparc64.
  • Has the ability to build Slackware packages with the following formats: TGZ, TBZ, TLZ and TXZ.
  • Has the ability to create files needed for slapt-get support.
  • Has the ability to manage configuration files, with or without "noreplace" attribute, and to retain the original permissions, using standard Slackware tools.
  • Has the ability to create correct packages even running as user, because the compressed tarballs (tar-1.13 compatible) are generated by its internally engine.
  • Has the ability to install/upgrade the generated packages using standard Slackware tools (only running as root, of course)
  • Has the ability to download (and verify the checksum) of the required files, using any protocol supported by libCURL (HTTP, HTTPS, FTP, FTPS, file, etc.)
  • Has the ability to create (and use) source packages, as TXZ archives.
  • Has the ability to allows very easy creation of split/multiple packages.

Now the bad news:

pkgbuild uses scripts similar to the RPM spec's, but not identical. These build scripts use the extension ".pkgspec".

To use pkgbuild, you will need to learn the syntax of it's scripts.

An example script is below:
Code:
# PkgBuild Spec for <mysql> package(s)

Name:     mysql
Version:  5.1.46
Release:  1

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

%package
Group:    CORE_APPS

Requires: gcc >= 4.4.3-%{__arch}-2
Requires: glibc-solibs >= 2.11.1-%{__arch}-2
Requires: ncurses >= 5.7-%{__arch}-1
Requires: openssl >= 0.9.8n-%{__arch}-1 | openssl-solibs >= 0.9.8n-%{__arch}-1
Requires: perl >= 5.10.1-%{__arch}-1
Requires: zlib >= 1.2.3-%{__arch}-2

%package embedded
Group:    LIBS

Requires: gcc >= 4.4.3-%{__arch}-2
Requires: glibc-solibs >= 2.11.1-%{__arch}-2
Requires: zlib >= 1.2.3-%{__arch}-2

%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-----------------------------------------------------#
mysql (SQL-based relational database server)

MySQL is a fast, multi-threaded, multi-user, and robust SQL
(Structured Query Language) database server.  It comes with a nice API
which makes it easy to integrate into other applications.

The home page for MySQL is http://www.mysql.com/

%description embedded
# 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-----------------------------------------------------#
mysql-embedded (Embedded SQL-based relational database server)

MySQL is a fast, multi-threaded, multi-user, and robust SQL
(Structured Query Language) database server. 

This package contains the embedded version of MySQL server, which makes
it easy to integrate into other applications.

The home page for MySQL is http://www.mysql.com/

%begin

%setup

%{__chbuilddir}

CFLAGS="${CFLAGS:-%__optflags}" ; export CFLAGS ; \
CXXFLAGS="${CXXFLAGS:-%__optflags -felide-constructors -fno-exceptions -fno-rtti}" ; export CXXFLAGS ; \
CXX="gcc" ; export CXX ; \
  ./configure \
    --prefix=%{_prefix} \
    --libdir=%{_libdir} \
    --with-mysqld-user=mysql \
    --with-unix-socket-path=%{_localstatedir}/run/mysql/mysql.sock \
    --localstatedir=%{_localstatedir}/lib/mysql \
    --mandir=%{_mandir} \
    --infodir=%{_infodir} \
    --enable-assembler \
    --without-debug \
    --enable-thread-safe-client \
    --with-extra-charsets=complex \
    --with-ssl=/usr \
    --enable-largefile \
    --with-innodb \
    --with-readline \
    %{__configure_flags}

%begin build

%{__make} %{_smp_mflags}

%begin install

%{__make} install DESTDIR=$__installdir

# install additional headers needed for building external engine plugins
for i in sql include regex; do
  for j in $i/*.h; do
    %{__install} -m 644 $j $__installdir%{_includedir}/mysql/
  done
done

%{__mkdir_p} $__installdir%{_includedir}/mysql/atomic

for i in include/atomic/*.h; do
  %{__install} -m 644 $i $__installdir%{_includedir}/mysql/atomic/
done

# The ./configure option to omit this has gone away, so we'll omit it the old-fashioned way.
# It's all in the source tarball if you need it.
%{__rm} -rf $__installdir%{_prefix}/sql-bench

# Install support files
%{__mkdir_p} $__installdir%{_sysconfdir}

%{__cp} -af support-files/my-{huge,large,medium,small}.cnf $__installdir%{_sysconfdir}

# Install docs
mkdir -p $__installdir%{_docdir}/Docs

( cd Docs
# Seems most of the Docs/* are gone, but we'll leave the cp stuff in case it returns.
#  %{__cp} -af INSTALL-BINARY *.html *.txt Flags \
  %{__cp} -af INSTALL-BINARY \
     $__installdir%{_docdir}/Docs
)
## Too large to justify since the .html version is right there:
#%{__rm} -f $__installdir%{_docdir}/Docs/manual.txt

# This is the directory where databases are stored
%{__mkdir_p} $__installdir%{_localstatedir}/lib/mysql
# This is where the socket is stored
%{__mkdir_p} $__installdir%{_localstatedir}/run/mysql

# Do not include the test suite:
%{__rm} -rf $__installdir%{_prefix}/mysql-test

# Add init script:
%{__mkdir_p} $__installdir%{_sysconfdir}/rc.d
# This is intentionally chmod 644.
%{__cat} %SOURCE0 > $__installdir%{_sysconfdir}/rc.d/rc.mysqld

# Add some handy library symlinks:
if [ -r $__installdir%{_libdir}/mysql/libmysqlclient.so.16 ]; then
  ( cd $__installdir%{_libdir}
    %{__rm} -f libmysqlclient.so libmysqlclient.so.16

    %{__ln} -sf mysql/libmysqlclient.so .
    %{__ln} -sf mysql/libmysqlclient.so.16 .
  )
else
  exit 1
fi
if [ -r $__installdir%{_libdir}/mysql/libmysqlclient_r.so.16 ]; then
  ( cd $__installdir%{_libdir}

    %{__rm} -f libmysqlclient_r.so libmysqlclient_r.so.16

    %{__ln} -sf mysql/libmysqlclient_r.so .
    %{__ln} -sf mysql/libmysqlclient_r.so.16 .
  )
else
  exit 1
fi

# Final cleanup
#%{__rm} -f $__installdir%{_libdir}/*.so.?
%{__rm} -f $__installdir%{_infodir}/dir

######################################################################
# Build and install the MySQL Embedded Server

%{__make} distclean

CFLAGS="${CFLAGS:-%__optflags}" ; export CFLAGS ; \
CXXFLAGS="${CXXFLAGS:-%__optflags -felide-constructors -fno-exceptions -fno-rtti}" ; export CXXFLAGS ; \
CXX="gcc" ; export CXX ; \
  ./configure \
    --prefix=%{_prefix} \
    --libdir=%{_libdir} \
    --datadir=%{_datadir} \
    --sysconfdir=%{_sysconfdir}/mysql \
    --libexecdir=%{_libexecdir} \
    --localstatedir=%{_localstatedir}/lib/mysql \
    --without-docs \
    --without-man \
    --without-server \
    --with-embedded-server \
    --without-innodb \
    --without-berkeley-db \
    --without-row-based-replication \
    --without-readline \
    --disable-shared \
    --with-charset=utf8 \
    --without-debug \
    --with-pthread \
    --without-ssl \
    --without-query-cache \
    --without-geometry \
    --with-pic

%{__make} %{_smp_mflags}

%{__cp} -a libmysqld/libmysqld.a $__installdir%{_libdir}/mysql/

%files
%defattr(-,root,root,-)
%doc COPYING ChangeLog EXCEPTIONS-CLIENT INSTALL-SOURCE README
%config %{_sysconfdir}/rc.d/rc.mysqld
%dir %attr(0750,mysql,mysql) %{_localstatedir}/lib/mysql
%dir %attr(0755,mysql,mysql) %{_localstatedir}/run/mysql
%{_sysconfdir}/my-*.cnf
%{_bindir}/*
%{_docdir}/Docs/*
%{_includedir}/mysql/atomic/*.h
%{_includedir}/mysql/*.h
%{_infodir}/mysql.info*
%{_libdir}/libmysqlclient.so*
%{_libdir}/libmysqlclient_r.so*
%{_libdir}/mysql/libdbug.a
%{_libdir}/mysql/libheap.a
%{_libdir}/mysql/libmyisam*.a
%{_libdir}/mysql/libmysqlclient*.a
%{_libdir}/mysql/libmysqlclient*.la
%{_libdir}/mysql/libmysqlclient*.so*
%{_libdir}/mysql/libmystrings.a
%{_libdir}/mysql/libmysys.a
%{_libdir}/mysql/libvio.a
%{_libdir}/mysql/plugin/*.a
%{_libdir}/mysql/plugin/*.la
%{_libdir}/mysql/plugin/*.so*
%{_libexecdir}/*
%{_mandir}/man1/*.1*
%{_mandir}/man8/*.8*
%{_datadir}/aclocal/mysql.m4
%{_datadir}/mysql/*

%files embedded
%defattr(-,root,root,-)
%{_libdir}/mysql/libmysqld.a

%changelog
* Friday 07 May 2010 Darth Vader <darkstarlinux@gmail.com> -
- Initial build.
Another example:

Code:
# PkgBuild Spec for <sudo> package(s)

Name:     sudo
Version:  1.7.2p6
Release:  1
Group:    CORE_APPS

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

%package
Requires: glibc-solibs >= 2.11.1-%{__arch}-2


%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-----------------------------------------------------#
sudo (give limited root privileges to certain users)

'sudo' is a command that allows users to execute some commands as
root.  The /etc/sudoers file (edited with 'visudo') specifies which
users have access to sudo and which commands they can run.  'sudo'
logs all its activities to /var/log/ so the system administrator
can keep an eye on things.


%begin

%setup

%configure \
  --with-getpass \
  --with-C2 \
  --with-env-editor \
  --disable-pam-session \
  --with-pam=no

%begin build

%{__make} %{_smp_mflags}

%begin install

%{__make} install DESTDIR=$__installdir

( cd $__installdir%{_bindir} ; %{__ln} -sf sudo sudoedit )

%{__rm} -f $__installdir%{_mandir}/man8/sudoedit.8

( cd $__installdir%{_mandir}/man8 ; %{__ln} -sf sudo.8 sudoedit.8 )

# Create the timestamp directory
%{__mkdir_p} $__installdir%{_localstatedir}/run/sudo

%files
%defattr(-,root,root,-)
%doc ChangeLog HISTORY INSTALL LICENSE PORTING README README.LDAP TROUBLESHOOTING UPGRADE WHATSNEW
%config(noreplace) %{_sysconfdir}/sudoers
%attr(4711,root,root) %{_bindir}/sudo
%{_bindir}/sudoedit
%attr(0755,root,root) %{_sbindir}/visudo
%{_libexecdir}/sudo_noexec.so
%{_mandir}/man5/sudoers.5*
%{_mandir}/man8/sudo.8*
%{_mandir}/man8/sudoedit.8*
%{_mandir}/man8/visudo.8*
%dir %attr(0700,root,root) %{_localstatedir}/run/sudo

%changelog
* Friday 07 May 2010 Darth Vader <darkstarlinux@gmail.com> -
- Initial build.
And here is another example:

Code:
# PkgBuild Spec for <most> package(s)

Name:     most
Version:  5.0.0a
Release:  1
Group:    CORE_APPS

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

%package
Requires: glibc-solibs >= 2.11.1-%{__arch}-2
Requires: slang >= 2.2.2-%{__arch}-1


%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-----------------------------------------------------#
most (another pager, like 'more' and 'less')

most is a paging program that displays, one windowful at a time, the
contents of a file on a terminal.  Unlike other well-known paging
programs, most supports multiple windows and can scroll left and
right.  Why settle for less?

'most' was written by John E. Davis.


%begin

%setup

%configure --datarootdir=%{_prefix}

%begin build

%{__make} %{_smp_mflags}

%begin install

%{__make} install DESTDIR=$__installdir

%{__rm} -rf $__installdir%{_docrootdir}/%{__name}

%files
%defattr(-,root,root,-)
%doc README changes.txt lesskeys.rc most-fun.txt most.doc most.rc
%{_bindir}/most
%{_mandir}/man1/most.1*

%changelog
* Friday 07 May 2010 Darth Vader <darkstarlinux@gmail.com> -
- Initial build.
The major advantage is that using this scripting language and its macros, you can easily achieve different architecture packages. For example, Slackware and Slackware64 and even an Sparc port could use a unified source tree.

Of course, you wonder why we have created us this tool, if we plan to further improve this pkgbuild, and why we want to offer it to Slackware users.

We'll be honest. pkgbuild is a companion tool of DPM, which is a complete packages management solution derived from lpmtool and that we intend to use it in future. There is also a tool called dpmbuild, which uses a similar scripting language, but which generates DPM packages.

In fact, pkgbuild is a simplified version of dpmbuild, being limited by the Slackware package format. I.e. for scripts, DPM packages supports pre/post installation scripts, pre/post upgrade scripts, triggers, etc..

Well, we use this pkgbuild to learn the use of its scripting language, and to ease our transition to the DPM packages.

Of course, we understand that not everyone will be willing to use our DPM's (i.e. we are sure about PV response to ideas like this: NO!), but also pkgbuild is a stand-alone tool for creating Slackware packages.

Therefore, we offer this tool to Slackware community and will continue to improve it as a way to promote the learning of this scripting language. Even after our complete transition to DPM packages, we continue to keep in sync pkgbuild and it's companion, dpmbuild.

Eventually, even if we abandon pkgbuild once, it is an open source application anyway, you have access to it's sources at current state and others can continue its development.

However, the pkgbuild SVN repository is here:

svn://svn.darkstarlinux.ro/svnroot/projects/trunk/playground/pkgbuild

If you want to test and/or to use pkgbuild, you can find latest version here: http://ftp.darkstarlinux.ro/software/pkgbuild/

The current version is 1.0.27.

pkgbuild configuration requires a special method, so in the tarball you will find a script called "pkgbuild.build" which will compile pkgbuild, then pkgbuild will self-compile and the resulted Slackware package will be installed in the system.

Warning: don't build directly the pkgbuild with the triplet configure/make/make install without studying the "pkgbuild.build" script and passing the correct parameters.

Unfortunately, at this time, pkgbuild not have its own documentation, so we suggest now, you read the documentation of dpmbuild, which can be found here: http://ftp.darkstarlinux.ro/software...tml/build.html

There are following differences between dpmbuild and pkgbuild:

pkgbuild accept the header "Summary" or "Changelog" section, but ignores it.

Sadly, the documentation is not exactly up-to date, both pkgbuild and dpmbuild use a different version for descriptions than the one described in the documentation, as seen in these example scripts (using the "Description" sections).

pkgbuild uses the headers "Requires", "Conflicts" and "Suggests" if exists, with the syntax of slapt-get and their content will reach the files that you suspect them. This is specifically slapt-get files. Not add these headers and the files will not appear.

pkgbuild uses the headers "Groups" if exists, and write it's content in the file install/slack-groups. This is an specifically DARKSTAR file. Not add these headers and the file will not appear.

Compared with dpmbuild, pkgbuild accept only two script sections: "%pre" and "%post". Their content will written on install/doinst.sh, in order that you suspect: "%pre" content on top, "%post" content on bottom.

Also the single accepted script "interpreter" is (of course): "/bin/sh" or smart process the command /sbin/ldconfig, aka %{__ldconfig}.

To control the tarballs compression format, use the header:

Code:
UseCompression: GZip
Accepted values: None (generate uncompressed tarballs), GZip, BZip2, LZMA and XZ (or Default)

To control the symlinks management, use the header:

Code:
UseLinkadd: Append
Accepted values: None (the symlinks is leaved in place), Append or Prepend (or Default). In these cases, pkgbuild "move the symlinks" on install/doinst.sh.

pkgbuild generates source packages as XZ compressed tarballs, with the name format: <name>-<version>-<release>.src.txz

Therefore, pkgbuild can use these source packages to build packages, using the parameter -r.

I.e. to rebuild the source mysql-5.1.46-1.src.txz with the architecture i586 and to install/upgrade all resulted packages, you can use:

Code:
pkgbuild -a i586 -ri mysql-5.1.46-1.src.txz
Also... The equivalent of $BUILD is the header "Release". If you want to use always an $TAG equivalent (i.e "SBo"), build and install pkgbuild with the command:

Code:
pkgbuild.build --with-buildtag="SBo"
or locally use the header:

Code:
BuildTag: SBo
In these cases, the "release" value will become <release><buildtag> (i.e. "3SBo").

A few words about the files attribute %config and %config(noreplace).

Suppose you want to configure two files:

Code:
%config(noreplace) %{_sysconfig}/rc.d/rc.init1.conf
%config %{_sysconfig}/rc.d/rc.init1
After compiling the package, we look in tarball and we see that these files have the extension ".pkgnew"

Code:
/etc/rc.d/rc.init1.conf.pkgnew
/etc/rc.d/rc.init1.pkgnew
After you install this package, we have the following situation in system:

Code:
/etc/rc.d/rc.init1.conf
/etc/rc.d/rc.init1.conf.pkgnew.20100525-210904
/etc/rc.d/rc.init1
/etc/rc.d/rc.init1.pkgsave.20100525-210904
What happened?

pkgbuild added in to install/doinstall.sh special instructions, and when you installed the package, our standard installpkg executed:

File /etc/rc.d/rc.inet1.conf differ by /etc/rc.d/rc.inet1.conf.pkgnew therefore /etc/rc.d/rc.inet1.conf.pkgnew was saved as /etc/rc.d/rc.inet1.conf.pkgnew.$DATE

File /etc/rc.d/rc.inet1 differ by /etc/rc.d/rc.inet1.pkgnew therefore /etc/rc.d/rc.inet1 was saved as /etc/rc.d/rc.inet1.pkgsave.$DATE and /etc/rc.d/rc.inet1.pkgnew replaced the original file.

In both cases, the original file permissions are copied to the new files.

Therefore, the %config(noreplace) attribute is useful for configuration files, and %config attribute for files that need backup. I.e. the boot scripts.

A Slackware standard behavior will be offered by %config(noreplace).

-------------
That's it. Not everything is just perfectly, but is usable. You have to remember that pkgbuild is considered experimentally until a serious testing. Don't use it in production machines!

I wait your opinion, questions, your suggestions for improvements, and why not? your bug-reports or even your contributions.
 
Old 05-26-2010, 08:07 AM   #2
koenigdavidmj
Member
 
Registered: Oct 2009
Posts: 73

Rep: Reputation: 25
Doesn't seem like this gets me much that SlackBuild scripts do not, yet requires that I learn a whole new format. Plus, there are already plenty of SlackBuild scripts ready to use.
 
1 members found this post helpful.
Old 05-26-2010, 08:39 AM   #3
AlvaroG
Member
 
Registered: Jul 2009
Location: Canelones, Uruguay
Distribution: Slackware
Posts: 128

Rep: Reputation: 31
Agree with koenigdavidmj: a package builder for a modern Slackware system should have support for SlackBuild scripts. Otherwise, it's just "another incompatible way to do it". Maybe pkgbuild is a hugely better tool than sbopkg and src2pkg, but those two are already well known and they "Just Work".

When reading your description I hoped to see some sbopkg-like functionality. Add that, and I think you'll get a lot more enthusiasm (from me at least, not that I am anyone important :-D)


Regards
 
1 members found this post helpful.
Old 05-26-2010, 11:59 AM   #4
LuckyCyborg
Member
 
Registered: Mar 2010
Posts: 124

Rep: Reputation: 19
@Darth Vader: First of all, I do not think Slackare will adopt your pkgbuild because it's too RPM-ish to be accepted by The Power That Be. But others may will be consider it useful ...

In fact, I think is very good that Slackware has a advanced package builder in the kind of RPM. Ultimately, no matter how they are built packages for us, the users.

So let's playing with pkgbuild!

I installed pkgbuild-1.0.27 in Slackware-13.1, running specified script, pkgbuild was installed correctly.

First, I was curious if your first example of pkgspec, can be compiled. I suspect that the Source0 (rc.mysqld) is the rc.d script from Slackware sources. Therefore, I copied your example as mysql.pkgspec in a directory, also the mysql-5.1.46.tar.xz and rc.mysqld.gz, from Slackware sources.

I executed the command:

Code:
pkgbuild mysql.pkgspec
Ouch! First mistake! pkgbuild not find these sources. Yeah! I use files compressed different.

I decompressed rc.mysqld.gz and I modified my pkgspec as such:

Code:
# Sources
Source:   %{__name}-%{__version}.tar.xz
Source0:  rc.mysqld
Seem like pkgbuild known also to use the tar.xz tarballs too.

The build started, worked fine and pkgbuild generated in my /tmp directory this files:

Code:
mysql-5.1.46-1.src.txz
mysql-5.1.46-1.src.txz.md5
mysql-5.1.46-i486-1.txt
mysql-5.1.46-i486-1.txz
mysql-5.1.46-i486-1.txz.md5
mysql-embedded-5.1.46-i486-1.txt
mysql-embedded-5.1.46-i486-1.txz
mysql-embedded-5.1.46-i486-1.txz.md5
I tried to rebuild the src.txz to i686 architecture, with the command:

Code:
pkgbuild -a i686 -r mysql-5.1.46-1.src.txz
The build worked and pkgbuild generated in my /tmp, these files:

Code:
mysql-5.1.46-i686-1.txt
mysql-5.1.46-i686-1.txz
mysql-5.1.46-i686-1.txz.md5
mysql-embedded-5.1.46-i686-1.txt
mysql-embedded-5.1.46-i686-1.txz
mysql-embedded-5.1.46-i686-1.txz.md5
WOW! That's nice! I luv the i686 packages!

Also, I was curious if pkgbuild meets the Slackware package standards. Here's what I found in install/doinst.sh of package mysql-5.1.46-i486-1.txz:

Code:
#!/bin/sh

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

config() {
  # By default, we don't use the "noreplace" option:
  NOREPLACE=0
  if [ "$1" = "-noreplace" ]; then
    NOREPLACE=1
    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
}

( cd usr/lib ; rm -rf libmysqlclient.so.16 )
( cd usr/lib ; ln -sf mysql/libmysqlclient.so.16 libmysqlclient.so.16 )
( cd usr/lib ; rm -rf libmysqlclient.so )
( cd usr/lib ; ln -sf mysql/libmysqlclient.so libmysqlclient.so )
( cd usr/lib ; rm -rf libmysqlclient_r.so.16 )
( cd usr/lib ; ln -sf mysql/libmysqlclient_r.so.16 libmysqlclient_r.so.16 )
( cd usr/lib ; rm -rf libmysqlclient_r.so )
( cd usr/lib ; ln -sf mysql/libmysqlclient_r.so libmysqlclient_r.so )
( cd usr/lib/mysql ; rm -rf libmysqlclient.so.16 )
( cd usr/lib/mysql ; ln -sf libmysqlclient.so.16.0.0 libmysqlclient.so.16 )
( cd usr/lib/mysql ; rm -rf libmysqlclient.so )
( cd usr/lib/mysql ; ln -sf libmysqlclient.so.16.0.0 libmysqlclient.so )
( cd usr/lib/mysql ; rm -rf libmysqlclient_r.so.16 )
( cd usr/lib/mysql ; ln -sf libmysqlclient_r.so.16.0.0 libmysqlclient_r.so.16 )
( cd usr/lib/mysql ; rm -rf libmysqlclient_r.so )
( cd usr/lib/mysql ; ln -sf libmysqlclient_r.so.16.0.0 libmysqlclient_r.so )
( cd usr/lib/mysql/plugin ; rm -rf ha_archive.so.0 )
( cd usr/lib/mysql/plugin ; ln -sf ha_archive.so.0.0.0 ha_archive.so.0 )
( cd usr/lib/mysql/plugin ; rm -rf ha_archive.so )
( cd usr/lib/mysql/plugin ; ln -sf ha_archive.so.0.0.0 ha_archive.so )
( cd usr/lib/mysql/plugin ; rm -rf ha_blackhole.so.0 )
( cd usr/lib/mysql/plugin ; ln -sf ha_blackhole.so.0.0.0 ha_blackhole.so.0 )
( cd usr/lib/mysql/plugin ; rm -rf ha_blackhole.so )
( cd usr/lib/mysql/plugin ; ln -sf ha_blackhole.so.0.0.0 ha_blackhole.so )
( cd usr/lib/mysql/plugin ; rm -rf ha_example.so.0 )
( cd usr/lib/mysql/plugin ; ln -sf ha_example.so.0.0.0 ha_example.so.0 )
( cd usr/lib/mysql/plugin ; rm -rf ha_example.so )
( cd usr/lib/mysql/plugin ; ln -sf ha_example.so.0.0.0 ha_example.so )
( cd usr/lib/mysql/plugin ; rm -rf ha_federated.so.0 )
( cd usr/lib/mysql/plugin ; ln -sf ha_federated.so.0.0.0 ha_federated.so.0 )
( cd usr/lib/mysql/plugin ; rm -rf ha_federated.so )
( cd usr/lib/mysql/plugin ; ln -sf ha_federated.so.0.0.0 ha_federated.so )
( cd usr/lib/mysql/plugin ; rm -rf ha_innodb_plugin.so.0 )
( cd usr/lib/mysql/plugin ; ln -sf ha_innodb_plugin.so.0.0.0 ha_innodb_plugin.so.0 )
( cd usr/lib/mysql/plugin ; rm -rf ha_innodb_plugin.so )
( cd usr/lib/mysql/plugin ; ln -sf ha_innodb_plugin.so.0.0.0 ha_innodb_plugin.so )
( cd usr/lib/mysql/plugin ; rm -rf libdaemon_example.so.0 )
( cd usr/lib/mysql/plugin ; ln -sf libdaemon_example.so.0.0.0 libdaemon_example.so.0 )
( cd usr/lib/mysql/plugin ; rm -rf libdaemon_example.so )
( cd usr/lib/mysql/plugin ; ln -sf libdaemon_example.so.0.0.0 libdaemon_example.so )
( cd usr/lib/mysql/plugin ; rm -rf mypluglib.so.0 )
( cd usr/lib/mysql/plugin ; ln -sf mypluglib.so.0.0.0 mypluglib.so.0 )
( cd usr/lib/mysql/plugin ; rm -rf mypluglib.so )
( cd usr/lib/mysql/plugin ; ln -sf mypluglib.so.0.0.0 mypluglib.so )

config etc/rc.d/rc.mysqld.pkgnew
However, a suggestion. I noticed a slightly different "config" function, which accepts parameters. It is how installpkg is instructed to configure different the config files, I guess. Cool thing, but with some changes this "config" can be used by another builders, too.

My proposal is that the default "config" method to become "use NOREPLACE", like the Slackware things:

Code:
--- doinst.sh.orig	2010-05-25 14:21:18.000000000 +0300
+++ doinst.sh	2010-05-26 13:12:44.421816463 +0300
@@ -4,10 +4,10 @@
 INSTALLDATE="`date '+%Y%m%d-%H%M%S'`"
 
 config() {
-  # By default, we don't use the "noreplace" option:
-  NOREPLACE=0
-  if [ "$1" = "-noreplace" ]; then
-    NOREPLACE=1
+  # We use the "noreplace" option by default:
+  NOREPLACE=1
+  if [ "$1" = "-replace" ]; then
+    NOREPLACE=0
     shift 1
   fi
   NEWFILE="$1"
@@ -79,4 +79,4 @@
 ( cd usr/lib/mysql/plugin ; rm -rf mypluglib.so )
 ( cd usr/lib/mysql/plugin ; ln -sf mypluglib.so.0.0.0 mypluglib.so )
 
-config etc/rc.d/rc.mysqld.pkgnew
+config -replace etc/rc.d/rc.mysqld.pkgnew
Okay, my first try to write an pkgspec, after reading pkgbuild (dpmbuild?) documentation. I chose a little app from Slackware sources, vbetool. After several attempts, below is my first functional pkgspec. I tried to copy your style, but without "ignored" or slapt-get elements.

Code:
# PkgBuild Spec for <vbetool> package(s)

Name:     vbetool
Version:  1.1
Release:  1

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

%package
# This section must be defined

%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-----------------------------------------------------#
vbetool (video bios execution tool)

vbetool is a small application that executes code from the BIOS of
your video card.

This is mostly useful for reinitialising the hardware, for instance
after ACPI suspend/resuming.

Homepage: http://www.codon.org.uk/~mjg59/vbetool/


%begin

%setup

%configure \
  --docdir=%{_docdir} --with-x86emu

%begin build

%{__make} %{_smp_mflags}

%begin install

%{__make} install DESTDIR=$__installdir

%files
%defattr(-,root,root,-)
%doc COPYING
%{_sbindir}/vbetool
%{_mandir}/man1/vbetool.1*
A new test. You said that pkgbuild can download sources. So, I removed the vbetool source tarball and I changed the line "Source" as follows:

Code:
Source:   http://www.codon.org.uk/~mjg59/vbetool/download/%{__name}-%{__version}.tar.gz
pkgbuild download source successfully and build work properly. Interestingly, it has not downloaded the tarball in the current directory, but elsewhere. However, vbetool-1.1.tar.gz file is present in vbetool-1.1-1.src.txz.

Hmm ... It is wrong to trust the downloaded files. I think pkgbuild it's wrong using downloaded files without verifying them. But he can check these files? I found no indications anywhere on how to proceed. Therefore, I bet on his RPM-ish behavior. So, rpmbuild uses the instruction "Source-md5:" to check the downloaded files. I checked the source tarball MD5 and I added:

Code:
# Sources checksum
Source-md5: ffb03b118867a02296d7449019ad8846
Seem like it works, because if I change the last "6" in to "0", the build failed with the message:

Code:
Invalid MD5 checksum: vbetool-1.1.tar.gz
The bad thing is that pkgbuild use downloaded files even it can't check these sources. This is a bad behavior.

Also, I checked if pkgbuild can use SHA1 checksums with instruction "Source-sha1:". Seem like that pkgbuild ignore instructions like that or the support for SHA1 doesn't exists. That's bad. Will be nice if pkgbuild can use SHA1 checksums.

Now, I was curious about how pkgbuild manage the descriptions. The generated install/slack-desc file from my vbetool package is nice and so Slackware-ish:

Code:
# HOW TO EDIT THIS FILE:
# The "handy ruler" below makes it easier to edit a package description. Line
# up the first '|' above the ':' following the base package name, and the '|'
# on the right side marks the last column you can put a character in. You must
# make exactly 11 lines for the formatting to be correct. It's also customary
# to leave one space after the ':'.

       |-----handy-ruler------------------------------------------------------|
vbetool: vbetool (video bios execution tool)
vbetool:
vbetool: vbetool is a small application that executes code from the BIOS of
vbetool: your video card.
vbetool:
vbetool: This is mostly useful for reinitialising the hardware, for instance
vbetool: after ACPI suspend/resuming.
vbetool:
vbetool: Homepage: http://www.codon.org.uk/~mjg59/vbetool/
vbetool:
vbetool:
vbetool:
vbetool:
But, how it works if I don't respect the Slackware style formatting in the pkgspec? I know that rpmbuild have ability to reformat the descriptions, pkgbuild can do this thing?

I changed in pkgspec the "description" section like below:

Code:
%description

vbetool (video bios execution tool)

vbetool is a small application that executes code from the BIOS of your video card.

This is mostly useful for reinitialising the hardware, for instance after ACPI suspend/resuming.

Homepage: http://www.codon.org.uk/~mjg59/vbetool/
and here is the resulted package description:

Code:
# HOW TO EDIT THIS FILE:
# The "handy ruler" below makes it easier to edit a package description. Line
# up the first '|' above the ':' following the base package name, and the '|'
# on the right side marks the last column you can put a character in. You must
# make exactly 11 lines for the formatting to be correct. It's also customary
# to leave one space after the ':'.

       |-----handy-ruler------------------------------------------------------|
vbetool: vbetool (video bios execution tool)
vbetool:
vbetool: vbetool is a small application that executes code from the BIOS of your
vbetool: video card.
vbetool:
vbetool: This is mostly useful for reinitialising the hardware, for instance
vbetool: after ACPI suspend/resuming.
vbetool:
vbetool: Homepage: http://www.codon.org.uk/~mjg59/vbetool/
vbetool:
vbetool:
vbetool:
vbetool:
Ouch! pkgbuild tried to reformat the text, but failed! In the third line, text exceeds the handy-ruler. I think this can be called bug even if description reformatting is an un-documented feature.

Well, I hope my observations will be useful.
 
1 members found this post helpful.
Old 05-26-2010, 01:12 PM   #5
rpedrica
Member
 
Registered: Nov 2008
Location: Cape Town
Distribution: Slackware64 -current
Posts: 208

Rep: Reputation: 27
I have to say any new addition to the Slackware environment is welcome. However the config syntax appears overly complex to me especially compared to something like SlackBuild. Also src2pkg makes package creation a snap even for novices. Good luck for your project in any case.
 
1 members found this post helpful.
Old 05-26-2010, 02:06 PM   #6
LuckyCyborg
Member
 
Registered: Mar 2010
Posts: 124

Rep: Reputation: 19
Quote:
Originally Posted by rpedrica View Post
However the config syntax appears overly complex to me especially compared to something like SlackBuild. Also src2pkg makes package creation a snap even for novices.
It seems like that the pkgbuild script syntax is a kind of RPM simplified. If you worked with RPM specs, you easily understand this syntax.

Okay, I worked a little with RPM specs in my past, can I be biased.

Anyways, pkgbuild seems to be written for those who build RPMs and they want to make Slackware packages, or for Slackware gurus.

I think that the good part is: with that this kind of builder, they can create high-quality packages. Has a high reproducibility.

Last edited by LuckyCyborg; 05-26-2010 at 02:08 PM.
 
1 members found this post helpful.
Old 05-26-2010, 03:31 PM   #7
dive
Senior Member
 
Registered: Aug 2003
Location: UK
Distribution: Slackware
Posts: 3,211

Rep: Reputation: 292Reputation: 292Reputation: 292
Well in my opinion the standard slackbuild script, which is a plain shell script, is still the best way to build packages. I don't want and neither see the need to learn a whole new syntax for spec files.

I also don't see the need to make something in C++ when a shell script will do. Slackbuilds are far more transparent to the user in my opinion and I don't see any need to change that right now. Not to mention that that is what Pat has decided to go with for all the stock packages.
 
1 members found this post helpful.
Old 05-26-2010, 03:32 PM   #8
dive
Senior Member
 
Registered: Aug 2003
Location: UK
Distribution: Slackware
Posts: 3,211

Rep: Reputation: 292Reputation: 292Reputation: 292
Quote:
Originally Posted by LuckyCyborg View Post
I think that the good part is: with that this kind of builder, they can create high-quality packages. Has a high reproducibility.
Not any higher quality than a slackbuild script.
 
1 members found this post helpful.
Old 05-26-2010, 04:03 PM   #9
LuckyCyborg
Member
 
Registered: Mar 2010
Posts: 124

Rep: Reputation: 19
Quote:
Originally Posted by dive View Post
Well in my opinion the standard slackbuild script, which is a plain shell script, is still the best way to build packages. I don't want and neither see the need to learn a whole new syntax for spec files.

I also don't see the need to make something in C++ when a shell script will do. Slackbuilds are far more transparent to the user in my opinion and I don't see any need to change that right now. Not to mention that that is what Pat has decided to go with for all the stock packages.
Well, talking about transparency versus control...

Debugging my build, out of curiosity, I just discovered that my vbetool build's command:

Code:
%configure \
  --docdir=%{_docdir} --with-x86emu
is equivalent in to a SlackBuild case with:

Code:
cd $TMP/${PKGNAM}-$VERSION

CFLAGS="${CFLAGS:--O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i486 -mtune=i686 -fasynchronous-unwind-tables}" \
CXXFLAGS="${CXXFLAGS:--O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i486 -mtune=i686 -fasynchronous-unwind-tables}" \
FFLAGS="${FFLAGS:--O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i486 -mtune=i686 -fasynchronous-unwind-tables}" \
./configure \
    --prefix=/usr \
    --exec-prefix=/usr \
    --bindir=/usr/bin \
    --sbindir=/usr/sbin \
    --sysconfdir=/etc \
    --datadir=/usr/share \
    --includedir=/usr/include \
    --libdir=/usr/lib \
    --libexecdir=/usr/libexec \
    --localstatedir=/var \
    --sharedstatedir=/usr/com \
    --mandir=/usr/man \
    --infodir=/usr/info \
    --program-prefix= \
    --program-suffix= \
    --build=i486-slackware-linux  \
    --docdir=/usr/doc/vbetool-1.1 \
    --with-x86emu

WOW! Simply WOW! As I was waiting, pkgbuild is as scrupulous as his eldest brother, rpmbuild. Err... dpmbuild?

At this level of builds accuracy... Sound so good!

BTW. You have not been curious, how does Fedora or OpenSuSE to possess and manage 10 times more packages than Slackware?

Here it's one of answers: builds accuracy and reproducibility in several platforms.
 
1 members found this post helpful.
Old 05-26-2010, 04:21 PM   #10
LuckyCyborg
Member
 
Registered: Mar 2010
Posts: 124

Rep: Reputation: 19
Quote:
Originally Posted by dive View Post
Not any higher quality than a slackbuild script.
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!
 
Old 05-26-2010, 04:25 PM   #11
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,260

Rep: Reputation: 645Reputation: 645Reputation: 645Reputation: 645Reputation: 645Reputation: 645
Quote:
Originally Posted by LuckyCyborg View Post
BTW. You have not been curious, how does Fedora or OpenSuSE to possess and manage 10 times more packages than Slackware?
They have more than a handful of active contributors? Think before you speak, perhaps.
 
Old 05-26-2010, 04:29 PM   #12
LuckyCyborg
Member
 
Registered: Mar 2010
Posts: 124

Rep: Reputation: 19
Quote:
Originally Posted by T3slider View Post
They have more than a handful of active contributors? Think before you speak, perhaps.
Ouch! You are right, somewhere. Out of beer, again!

Seem like it's time to stop posting today...
 
Old 05-26-2010, 04:33 PM   #13
dive
Senior Member
 
Registered: Aug 2003
Location: UK
Distribution: Slackware
Posts: 3,211

Rep: Reputation: 292Reputation: 292Reputation: 292
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
 
Old 05-26-2010, 04:34 PM   #14
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,260

Rep: Reputation: 645Reputation: 645Reputation: 645Reputation: 645Reputation: 645Reputation: 645
Quote:
Originally Posted by LuckyCyborg View Post
Seem like it's time to stop posting today...
Nonsense. The rest of your posts in this thread were very interesting, and as someone who was never going to try this out for myself it's nice to see how it works.
 
Old 05-26-2010, 04:44 PM   #15
LuckyCyborg
Member
 
Registered: Mar 2010
Posts: 124

Rep: Reputation: 19
Quote:
Originally Posted by T3slider View Post
Nonsense. The rest of your posts in this thread were very interesting, and as someone who was never going to try this out for myself it's nice to see how it works.
So, I'll continue tomorrow. In my time(zone) is 1 AM, now...
 
  


Reply

Tags
builder, package, slackware


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
What is the recommanded architecture for multi-distribution system ? lalebarde Linux - Distributions 2 03-01-2007 06:28 AM
Enable SMT on Clovertown Multi-Core architecture? sorenp Linux - General 0 01-24-2007 09:01 AM
architecture for slackware package? elyk Slackware 11 06-19-2004 04:21 PM


All times are GMT -5. The time now is 10:50 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration