Hi,

So I managed to finally get Slackware 12.2 operational on my box. Now the next step comes with installing various third party software, customized for build. I used to utilize Checkinstall -- prior to Slackware 12. Then I was reminded that ever since Slackware 12, Checkinstall has been introducing some issues that hasn't been resolved and could install a broken package which down road would come and bite you right on you-know-what. I brushed off such advice and continued on with my installation until the very first one that I built and got ready to install with Checkinstall went haywire. I've come to a conclusion that it is true that Checkinstall can and WOULD cause some issues with your installation.

Now I would like to know whether any package building tool similar to Checkinstall out there that can easily perform such functionality. I skimmed over Slackbuild (SBo) but scripting takes time and it's not very economic. Is there any other program that can help us Slackers?



Sincerely,

I use src2pkg now and recommend it highly. There are plenty of threads on src2pkg here so I won't describe it, but it is very flexible and reliable.

It takes a few minutes to learn about the general layout of a SlackBuild, and from there you can use a generic template to adapt to each package you want to build in literally seconds. 95% of SlackBuilds are identical besides the package name and version, it is only special cases that require additional work. Once you get it down, building with SlackBuilds (especially doing updates) is just as fast as any automated tool you will find out there.

That said, you might want to look into src2pkg. While it isn't my style personally, the developer (gnashley) is a regular here at LQ and works very hard on src2pkg to make it as foolproof and feature rich as possible.

I found a package tool called; slackpkg, which uses the main built in one. Just do a search for it, then download and install it. Also I have downloaded a newer version of; ntfs-3g tool, as a .tgz file to the desktop. So how do I install or upgrade this in Slackware 12.1,KDE ? I did try several ways in a konsole terminal as root with the slackpkg tool. And here is that tool site link; http://sourceforge.net/projects/slackpkg/

If you're coming from using checkinstall, you may find src2pkg a little difficult at first. That's because it's (as the name implies) going directly from a source package to a Slackware package. I had trouble getting it to find dependencies in non-default directories and some other issues if make required some other form than just "make"*. The solution I found was to unpack the sources and do the configure and make steps as necessary, then use the trackinstall tool included with src2pkg. It works essentially just like checkinstall did, although it seems like I've read that's not the best way to do things. It may get you going while you get over the learning curve of writing Slackbuild scripts or using all of the features in src2pkg though.

*gnashley, if you read that, I'm aware that you keep src2pkg in heavy development and any difficulties I had in the past were more likely user error than any shortcomings of src2pkg. In either case, I haven't used it in about a year so newer versions may also address the issues I had.

gilead, SpelledJ:

Thank you both for the life-saving recommendation on "src2pkg." It seems like it fits all the well-rounded Slackware package management tool I was looking for.


SpelledJ,

I wish I had read your comment earlier on because I was biting my pillow for now seeing any use for the actual "src2pkg" as it performs configuration and compilation... until I read the introduction page more carefully and stumbled upon "trackinstall" that, essentially comes with src2pkg and as you said, it works just like `checkinstall'. Can you please elaborate on your last statement regarding, "although it seems like I've read that's not the best way to do things"?



Update(1): I read the src2pkg FAQ and does say it's better to use src2pkg for the whole process because it tracks the creation and configuration all together. However, what I don't understand is that `src2pkg' uses a compressed form to perform all the necessary steps. This is redundant because if I am going to compile a source, I need to uncompress it first, run the `./configure --help' or read doc/INSTALL/README and what not, then go back to the compressed source and run 'src2pkg'. So why not just drop the "filename" at the end of the command line and make 'src2pkg' perform its task on the current directory?

Update(2): It seems like `src2pkg' by default set the prefix to `/usr'. Shouldn't it obey the default PREFIX set by application's `configure' file?

Update(3): Much thanks to gnashley for this great tool. Some of us poor souls wouldn't make it through the day without the magnanimous grace offered by people like you.

When I started using src2pkg all of the documentation wasn't completed, so I'm not sure that I ever knew why "configure/make/trackinstall" wasn't optimum. It sounds like you've found a reasonable explanation though. I wondered about why it always had to point to the compressed source as well because everything had to be unpacked first to found out how to construct the src2pkg command line options. I guess it would be easier to update packages with newer releases though if you kept the command you used. Then you could just point it at the new source package and get an updated package.

The behavior you describe in Update 2 is one of the problems I had with it. Trying to balance between installing the package where I wanted it and making sure the package's configure script could find libraries in Slackware was difficult for me. I had best results just using trackinstall.

I'll have to second what you've said in Update 3. I certainly don't mean to be critical of src2pkg, especially since gnashley is active on LQ and works hard to keep improving his project. At the time I just didn't have the patience to learn a new tool and was frustrated because I had relied on checkinstall and it didn't work anymore.

Since then, I've really only installed packages via slackbuilds.org. I've liked that system so much if a package I want isn't in there I'll put it on my "get to later" list rather than trying to install it. I haven't found much I've wanted to install that wasn't in there anyway. One of these days I'll really learn how to write my own Slackbuilds but haven't gotten to it yet.

Why should it? One of the important principles behind system management is being consistent in where you install things, so you know where they are, rather than having them spread out all over your directory tree. So, for example, the developer of software Y defaults to put it under /opt, because he organises his system that way. On my system where most of the software is installed under /usr, why would I want software Y to install under /opt?

Brian

There's an update on the checkinstall page, giving a link to the git repository. It says

I haven't tried it myself, but sounds like it should work.

Here's the page:
http://asic-linux.com.mx/~izto/checkinstall/

Try sbopkg, get it here. It is a really easy and effective way of managing the Sbo slackbuilds site.

samac

You have a valid point as far as centralization of package and installation management system. However, it doesn't serve a user's purpose once he selects a non-src2pkg-default location as the installation destination for his system. For instance, if I install every X program under `/my-x' then the package management tool is forcing me to have them under `/usr'. You can argue that by forcing the package management tool to take on a proactive role of assigning every installation under `/usr', you are effectively trickling down consistency, which again, by itself it is a worthy cause.

So we have three lines of selecting the destination of installation: 1) user's own 2) package management (i.e. src2pkg) 3) program's PREFIX. I think (1) precedes all other options and if such decision is aligned with the majority of configuration's PREFIX, the better. Once again, you do have a valid point here and I am not trying to smirch it by any means, however, I think the user is more suitable to make the final decision with the program's default PREFIX to fall back on. Taking your example, what if a user's default installation has been `/usr/custom' since the build of dozens of programs. Now all of sudden, the package management shifts the old location to `/usr' -- now we have discrepancies.

I got a cold feet yesterday when the Checkinstall 1.6.1 failed me miserably. This fella explains why the latest version has been buggy:

http://checkinstall.izto.org/cklist/msg00319.html


But I did manage to acquire the `git' version and I will eventually give it a try against the Apache httpd which Checkinstall failed to install. To be updated...

The new git version of checkinstall includes fixes that I came up with about a year ago for the core installwatch library -that's where the main problem was -not with checkinstall itself. Still it is pretty drude compared to src2pkg.

About src2pkg vs trackinstall, using src2pkg means you start with the compressed sources, no need to manually unpack them. trackinstall works much like checkinstall, that is you just unpack, configure and make 'normally' -that is manually. The the simple command trackinstall will do what checkinszall would basically do -that is create a package.

I encourage the use of the full src2pkg because it makes it easier for you to document and/or repeat your builds later, or even at the time of debugging. Once you have NAME*src2pkg script, you can repeat the whole build with just 'src2pkg -X'. And adding '-W' to that will clean up the temp files when done.
There are a few cases where it is easier to use trackinstall instead of src2pkg -usually this is just for pre-compiled binary content like video drivers or opera. There, you'll find it easier to just unpack the tarball, change the name of the directory to some sane name ($NAME-$VERSION), cd in there and run trackinstall. The tarckinstall frontend was written as an after-thought for those who are already comfortable with checkinstall or don't want everything done for them -just like <snap> that.

As for using --prefix=/usr, it is my inetrpretation and judgement that that is where *packaged* software should go. But if you wanna change that, put another default in /etc/src2pkg.conf or just use the -p='usr/local' from the command line. src2pkg makes it easy to override any settings you don't like, usually either from the command-line or in a NAME.src2pkg script (for case-by-case control), or in the src2pkg.conf file for 'always' settings. There are so many configurable things that I try to not boggle your mind with 100-150 command-line options. Only the most useful, necessary or often-used options can be easily set from command-line.
Some software is best(and rightly) installed in a non-standard place. src2pkg gives you the control. /usr is just the most sane default. Ahving a default makes it possible to build using no options whatever: 'src2pkg tarball' or even from the net:
'src2pkg URL-to-tarball'

Hi gnashley,

Your src2pkg program is really a more complete solution (so thanks for creating it ). I don't know if it's my bad luck or what, but I'm having some trouble with trackinstall.

I was using checkinstall without any issues until it broke, then I looked for something else and found src2pkg. Trackinstall is a checkinstall replacement but I don't remember being able to use it like I used checkinstall. I do configure && make, but then doing trackinstall gives me errors.

For example, to give another try, I've just installed src2pkg again and tried to install gtk-recordmydesktop-0.3.8 using it. src2pkg works beautifully, but if I unpack the sources myself and do ./configure && make, trackinstall gives

Of course, 'make install' works, so the 'install' rule must be there. What's the problem then? I'd love to be able to use trackinstall. I prefer this way because when I do installation from source, I usually look at the ./configure options (with --help) first and play with those a little bit. I know src2pkg can be run in interactive mode but doing this by hand is more convenient to me (and yeah, I'm a bit lazy to change my habits ). Thanks,

Ilgar

Last time I tried to build mplayer with src2pkg -e='--enable-gui' mplayer source archive.tar.bz2, the gmplayer symlink didn't get created. Is this a known problem, or should I try it again?