The 'Magic Package Maker' comes of age and changes its' name
SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
The 'Magic Package Maker' comes of age and changes its' name
Finally PkgBuild has reached version 1.0 and celebrates by changing its' name to 'src2pkg' (There was already a program called pkgbuild)
src2pkg adds several new features including:
- handle source RPM packages directly -no need to convert to tar.gz or tar.bz2 format before building
- handle conversion of 'foreign' binary packages such as '.rpm' and Debian '.deb' archives.
The simple command 'src2pkg tarball-name' will succesfully build an amazing variety of source types -maybe even some packages that you haven't been able to compile manually!
- added easy-to-use options for installing the package once created and for saving backups of any files overwritten on your system during building of the package.
I've found that src2pkg will successfully build nearly any source package you throw at it, if the sources can indeed be compiled on your system. Of course, making the 'perfect' package may still require a few extra lines in your build script or that extra options be given on the command-line. But most of the scripts I wrote for use with early versions of PkgBuild which included lines for unusual circumstances are now obsolete.
If you find some source package that src2pkg can't properly unpack, build and package, I'd really like to hear about it -I'm having trouble finding sources that 'challenge' it anymore, so let me know what doesn't work.(SRPM's which contain more than one tarball may give problems occassionally -but it will even build some stuff that has a different name inside the tarball)
src2pkg handles nearly any autoconf source, even incomplete or CVS sources and ones that use GNUmakefiles; simple sources with just a Makefile; imake-type sources; sources which use scons or jam instead of make
Package building has never been this easy, or more accurate -no more excuses for not having your own package repository for your favorite software. Porting other build scripts or rpm .spec files is really easy -usually all you need to get from them are the extra options passed to configure -takes just afew seconds to add that to a new src2pkg build script which src2pkg will generate for you, before or after building your package.
Decompression of .rpm and .deb archives in handled by the excellent proogram disrpm, which is included and installed to /usr/bin so you can use it apart from src2pkg. It actually succeeds in unpacking many rpm's where rpm2tgz and rpm2cpio fail -now you don't need rpm installed anymore to handle them, plus it also works for debian packages.
Awesome! May i be near the top to congratulate you!
Finally time to uninstall checkinstall =D
May I ask, what is your recommended directory structure for building and storing sources?
I started with just a /home/user/src directory for the tarballs, but found that messy. Now i've moved to a ~/tarball ~/src structure, one for downloading into and one for building in ... still messy. On top of this i've got a /home/packagebuild/packages directory for storing the built packages.
Have you tried compiling noteedit from source?
I would consider this to be the biggest challenge that I have come across, with layered dependencies, config command line options and a final python script to complete the install.
Piete, you can set up a build area rpm-style by making directories under /usr/src or wherever. One directory for sources, one for packages and one for all the builds. Then edit your src2pkg.conf file to point to these directories.
mkdir sources packages builds scripts
Then edit your scr2pkg.conf like this:
Then under the directory scripts set up a separate directory for each package. This is where you keep your scripts, patches and other material used by the build, if needed.
This is just an example. Note that you don't really have to assign SOURCES_DIR to keep all your tarballs in one place. You can always put them anywhere and just create a link to them from the individual directory where the build script is. Hard-coded paths also work, even if it isn't the same as SOURCES_DIR. To make this work you give SOURCE=/path/to/tarball instead of SOURCE_NAME=tarball
Another thing to consider when editing src2pkg.conf: The options as shown above are not easy to override. If you still want to be able to override the options when needed, write them like this:
To allend: I'm compiling noteedit at the moment. It was a little tricky to get going at first, mostly because I don't usually have KDE, QT, arts and python installed. Once I installed them (plus kdemultimedia and attr and acl) I was able to progress okay.
First I had to install tse3 which was straightforward except the sources need to be patched to compile with gcc-3.4 and for alsa support.
There are two slightly odd things about noteedit. First having to export KDEDIR and QTDIR before configuring and compiling. Plus, for some reason kdeguitar_excerpt fails to compile completely when compiled from the top source directory.
However this was easily solved by a just doing the confiure_source and compile_source steps manually. I'll upload the sources, patches, build scripts and packages a little later, but meanwhile this is all it really took to get a good package:
Run 'src2pkg -N noteedit-2.8.1.tar.gz' tzo produce an initial script. Then edit
it as below:
cd $SRC_DIR && ./configure
cd $SRC_DIR/kguitar_excerpt && make
# now compile the rest
cd $SRC_DIR && make
Voila! This makes a good example of how little intervention is needed even in drastic cases. These are exactly the steps which you will most often need to override, and you only have to substitue the same commands you'd give when compiling manually, except you need to use the $SRC_DIR variable.
Did I somewhere hear someone said that they sometimes unpack or do something with a .deb package just so as to trace or answer the question "what dependencies does a package have?"
Anyways, given "if that, the above" then I'm wondering if I could use this src2pkg on a .deb to get a dependency list and then to build the pkg *and* also build each of its dependency for Slackware 11.0.
(I've been to sourceforge and I'm unable to decipher the lingo there in order for me to understand exactly what I need in the way of dependencies for liferea which is an rss client)
IOW I'd like to have a liferea package and its dependency packages (few gnome libraries) for Slackware 11.0 (I'd want to run liferea from within KDE)
Too many probs with akregator rss client on KDE (maybe doesn't like my DSL modem or etc. but have to reload too too many times then still misses retrieving a few.
liferea on CentOS 4.4 does not do that -- it works fine for me without any problems. And I like the moz-firefox integration in CentOS. In liferea, click to read a thread and it opens for reading in Firefox. Nice. But my favorite distro is Slackware 11.0 running KDE
"use this src2pkg on a .deb to get a dependency list"
We've been doing this with source compiles for awhile, but only when a build fails. We search for an RPM .spec file or Debian control and show requires.
To see this use the -V option with src2pkg (or REPLAY_ERRORS=YES in script).
The new feature which *converts* .deb and .rpm binaries does something a
little different which is also available with source builds. When you convert the .deb we run ldd on the executables and show a list of the libraries required by the package. This is needed since you didn't comile them on your system and we don't know if if all deps are met, so we show you them. You can also do this when compiling sources (by passing SHOW_DEPS=YES)
Note that the former shows debian or rpm package names and the latter shows raw library names.
"build the pkg"
To convert a binary Debian .deb or .rpm archive just type the name as you find it. Examples:
"build each of its dependency for Slackware 11.0."
We don't do this, since we don't yet even support URL location of sources. However we make it easy to chain-build and install packages once you have the sources available and know what order they need to be in. This will work for source compiles or binary package conversions.
Just create a project area with a subdirectory for each package and make each script as usual.
Make a list of the package subdirectories in the desired copile order.
Create a small script to cd into each directory and run the build script there:
# If the packages are really chain-dependent you need this
for dir in cat COMPILE.list ; do
cd $dir and sh ./*.src2pkg
That was a pretty easy package, actually. I downloaded the sources from the debian pool along with the diff file which shows that it needs GTK2, atk, pango, cairo -all in your standard Slackware. It also requires GConf-2 and either gtkhtml2 or firefox/mozilla. GConf-2 needs ORbit2 as well.
You can get the GConf-2 and ORbit-2 stuff from here if you need them: http://distro.ibiblio.org/pub/linux/...E-COMPAT-2.10/
Once you have the above, you can compile liferea with just:
Found source archive: inkscape-0.45.tar.gz
Deleting old build files - Done
Creating working directories - PKG_DIR SRC_DIR Okay
Unpacking source archive - Done
Found sources: inkscape-0.45
Moving into SRC_DIR: inkscape-0.45-src-1
Found 'rpm2tgz' format:
Correcting file permissions - Done
Found configure script - Configuring sources using:
CFLAGS=-O2 -march=i486 -mtune=i686 ./configure --prefix=/usr
ERROR! Configuring sources has failed!
This usually happens because of missing libraries, or you
may need to pass extra options to configure using EXTRA_CONFIGS.
Found an RPM .spec file which shows this:
BuildRequires: libart_lgpl-devel >= 2.3.10
BuildRequires: libgnomeprintui22-devel >= 2.2.0
BuildRequires: libxml2-devel >= 2.4.24
src2pkg FAILURE in configure_source
However the end of a normal ./configure gives:
checking for Perl development environment... skipped
checking for Python development environment... skipped
checking for LCMS... yes
checking for INKSCAPE... configure: error: Package requirements (gdkmm-2.4 glibmm-2.4 gtkmm-2.4 gtk+-2.0 >= 2.8.0 libxml-2.0 >= 2.6.11 libxslt >= 1.0.15 cairo sigc++-2.0 >= 2.0.11 gthread-2.0 >= 2.0 libpng >= 1.2) were not met:
Package libpng12 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libpng12.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libpng12', required by 'cairo', not found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables INKSCAPE_CFLAGS
and INKSCAPE_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
So whilst I think src2pkg made a good try here in the face of adversity (I needed to reinstall libpng as somehow the .pc file had gone astray, I'm blaming slackpkg for that!) it could, it seems, have been more verbose with respect to the error - configure correctly identified the problem.
Running in the default QUIET mode turns off all the ouput from configure, make and make install. If you use the -V option, src2pkg will open a new xterm and rerun the failed command so you can see what the specific error was. You can also see the whole thing the first time around by using the -VV option to not suppress output.
It would take many.many thousands of lines of code to try and figure out what the errors are when something fails and do anything about it. My best idea(for down the road) is to parse out requires and congfigure/build commands from any existing .spec or control file and try those options when building has failed. Even this is just a stab in the dark, unless we used some form of real dependency checking and resolution. Note that I don't claim that src2pkg can or should do this -it's a very tall order indeed. Working out depends and chain-compile orders is nice work for an enthusiast. src2pkg makes the tedious rebuilds and fine tunign easier along the way.
I've considered several methods for building packages as non-root user. There are a couple of advantages and some disadvantages as well. Non-root builds are safer from a system standpoint, but some software doesn't work when compiled as a user and then installed as root.
You can easily do this though by using trackinstall. Just unpack, configure and compile your software as normal(manually, I mean). Then cd into the sources, su to root and make the package with 'trackinstall'.
Generally, compiling and trying to compile lots of unknown software on a production machine is not a good idea, unless you know how to fix things. I've tried to make src2pkg as dependable and trouble-free as possible when building as 'root' -note that SlackBuilds require you to be 'root' since makepkg itself requires it. One of the reasons we do the installation-tracking the way we do is to insure that everything on your system is exactly the way it was before you started -this happens even before package-making is finished.
I appreciate the feedback and suggestions and they are not lost on me. They do help shape the future of the program.