LinuxQuestions.org
Review your favorite Linux distribution.
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
 
LinkBack Search this Thread
Old 12-15-2008, 05:27 PM   #1
oxblood
Member
 
Registered: Jan 2004
Location: Atlanta, GA
Distribution: Slackware 12.2
Posts: 82

Rep: Reputation: 15
Package Management for Slackware 12.2


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,
 
Old 12-15-2008, 05:30 PM   #2
gilead
Senior Member
 
Registered: Dec 2005
Location: Brisbane, Australia
Distribution: Slackware64 14.0
Posts: 4,123

Rep: Reputation: 151Reputation: 151
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.
 
Old 12-15-2008, 05:34 PM   #3
MS3FGX
Guru
 
Registered: Jan 2004
Location: NJ, USA
Distribution: Slackware, Debian
Posts: 5,850

Rep: Reputation: 350Reputation: 350Reputation: 350Reputation: 350
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.
 
Old 12-15-2008, 06:46 PM   #4
james2b
Member
 
Registered: Feb 2007
Location: Washington state, USA
Distribution: Fedora 13, SUSE 11, Ubuntu 10.04, Mandriva 2010, Mint 8
Posts: 336

Rep: Reputation: 34
Question

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/

Last edited by james2b; 12-15-2008 at 06:48 PM. Reason: link
 
Old 12-15-2008, 06:51 PM   #5
SpelledJ
Member
 
Registered: Jun 2006
Location: Birmingham, AL
Distribution: Slackware64-13.1, 12.1
Posts: 119

Rep: Reputation: 20
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.
 
Old 12-15-2008, 07:19 PM   #6
oxblood
Member
 
Registered: Jan 2004
Location: Atlanta, GA
Distribution: Slackware 12.2
Posts: 82

Original Poster
Rep: Reputation: 15
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.

Last edited by oxblood; 12-15-2008 at 08:03 PM.
 
Old 12-15-2008, 08:56 PM   #7
SpelledJ
Member
 
Registered: Jun 2006
Location: Birmingham, AL
Distribution: Slackware64-13.1, 12.1
Posts: 119

Rep: Reputation: 20
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.
 
Old 12-15-2008, 10:22 PM   #8
BCarey
Senior Member
 
Registered: Oct 2005
Location: New Mexico
Distribution: Slackware
Posts: 1,420

Rep: Reputation: Disabled
Quote:
Originally Posted by oxblood View Post
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?
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
 
Old 12-16-2008, 03:10 AM   #9
Ilgar
Member
 
Registered: Jan 2005
Location: Istanbul, Turkey
Distribution: Slackware 14.1, Slackware64 14.1
Posts: 916

Rep: Reputation: 87
Quote:
Originally Posted by oxblood View Post
since Slackware 12, Checkinstall has been introducing some issues that hasn't been resolved
There's an update on the checkinstall page, giving a link to the git repository. It says

Quote:
In there you'll find support for at-style llibrary calls which fixes the incompatibility issues with newer utilities.
I haven't tried it myself, but sounds like it should work.

Here's the page:
http://asic-linux.com.mx/~izto/checkinstall/
 
Old 12-16-2008, 03:53 AM   #10
samac
Senior Member
 
Registered: Mar 2004
Location: Westray, Orkney
Distribution: Slackware64-14.1 (multi-lib) KDE 4.11.4
Posts: 1,398

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

samac
 
Old 12-16-2008, 08:05 AM   #11
oxblood
Member
 
Registered: Jan 2004
Location: Atlanta, GA
Distribution: Slackware 12.2
Posts: 82

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by BCarey View Post
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


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.
 
Old 12-16-2008, 08:07 AM   #12
oxblood
Member
 
Registered: Jan 2004
Location: Atlanta, GA
Distribution: Slackware 12.2
Posts: 82

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by Ilgar View Post
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/


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...
 
Old 12-16-2008, 08:56 AM   #13
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,724

Rep: Reputation: 449Reputation: 449Reputation: 449Reputation: 449Reputation: 449
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'
 
Old 12-16-2008, 11:59 AM   #14
Ilgar
Member
 
Registered: Jan 2005
Location: Istanbul, Turkey
Distribution: Slackware 14.1, Slackware64 14.1
Posts: 916

Rep: Reputation: 87
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

Quote:
# trackinstall
Client or user supplied NAME and VERSION: gtk-recordmydesktop-0.3.8
Creating working directories:
PKG_DIR=/tmp/gtk-recordmydesktop-0.3.8-pkg-1
Checking for 'install' rule -
NOTICE! No install rule in Makefile.
FAILED!
trackinstall FAILURE in GENERIC_INSTALL No executables found
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
 
Old 12-16-2008, 12:05 PM   #15
dugan
Senior Member
 
Registered: Nov 2003
Location: Canada
Distribution: distro hopper
Posts: 4,238

Rep: Reputation: 1299Reputation: 1299Reputation: 1299Reputation: 1299Reputation: 1299Reputation: 1299Reputation: 1299Reputation: 1299Reputation: 1299
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?
 
  


Reply

Tags
checkinstall, src2pkg


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
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Slackware Package Management Best Practices -{Jester}- Slackware 19 05-22-2008 12:46 AM
Slackware security - package management 52fitz Slackware 4 02-21-2006 03:28 PM
Slackware Package Management gonzalo76 Slackware 12 05-11-2004 07:20 PM
Slackware Package Management kemplej Slackware 1 12-22-2003 05:34 PM
slackware package management Vlad_M Slackware 6 08-15-2003 04:20 AM


All times are GMT -5. The time now is 08:38 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