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
 
Search this Thread
Old 12-09-2008, 01:00 AM   #1
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0
Posts: 3,475

Rep: Reputation: 530Reputation: 530Reputation: 530Reputation: 530Reputation: 530Reputation: 530
Updating Non-Stock Packages After a Slackware Release


Are there any guidelines or rules of thumb to help determine which non-stock packages should be recompiled after updating to a new Slackware release?

Some are obvious, such as virtual machine software or video driver kernel modules, or things just break. But otherwise?

Thanks again.
 
Old 12-09-2008, 02:23 AM   #2
zux
Member
 
Registered: Jul 2006
Location: latvia
Distribution: slackware
Posts: 127

Rep: Reputation: 16
it depends on what the software it is, most will work, but it's best to keep slackbuilds with the source and recompile if you need to (I have slackbuilds for all the packages i built and installed). But the only true way is to read the slackware changelog and to know exactly what that package uses in what way.
 
Old 12-09-2008, 02:46 AM   #3
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,189

Rep: Reputation: Disabled
The packages you build using SlackBuild scripts from slackbuilds.org, Robby Workman or written by me, all use "tags" which let you identify them easily. The same is true for the packages you can download from slacky.eu and other repositories.
For instance, my packages all have the tag "alien". You can easily get a listing of my packages you have installed, by running
Code:
ls /var/log/packages | grep "alien"
On my old box here, that has the following output:
Code:
clamav-0.94.2-i486-1alien
dansguardian-2.9.9.4-i486-1alien
par-1.52-i486-1alien
pcre-7.6-i486-1alien
terminus-font-4.26-noarch-1alien
tinyproxy-1.6.3-i486-1alien
xcowsay-1.1-i486-1alien
It becomes harder of course, when you installed software using configure; make; make install.

Eric
 
Old 12-09-2008, 05:55 AM   #4
GazL
Senior Member
 
Registered: May 2008
Posts: 3,319

Rep: Reputation: 881Reputation: 881Reputation: 881Reputation: 881Reputation: 881Reputation: 881Reputation: 881
I fall into the 'recompile it all' camp, myself. The entire Posix/UNIX philosophy seems to revolve around compatibility of source. Old binaries are pretty much an unknown quantity and they may work and they may not, or worse yet, they may work but with obscure bugs introduced due to some minor change in a library or header. It just seems much safer to my mind to recompile the lot. Ofcourse, recompiling with the new tool chain could potentially also introduce obscure bugs, but to my mind keeping everything consistent is worth the risk.

I was recently working on a patch for the initrd-tree that I've sent to Pat. To incorporate this properly into my system I need to re-run the mkinitrd.Slackbuild, but I've found that the version of busybox that current contains won't build with the 2.6.27 Kernel headers (a change to netfilter.h, which now appears to require the programs to also #include <netinet/in.h>). Using the latest busybox sources instead resolved the problem for me. Now, busybox is statically linked so running the old version of the package shouldn't hit any library incompatibilities, but if any of the system calls have changed then there could potentially be problems.

Owing to the way the Slackware team works, some old packages are carried through to each new release from the previous one. Pat is usually very good at keeping things working, so I trust his judgement on what needs recompiling for a new release and what doesn't, however, its not unusual to find the odd part of the source tree that fails to build after a new release. Though all sources are available, you can't actually recreate a specific slackware release from that releases source tree alone as there may be parts that require a much older release in order to build correctly. I've always found this disconnect between the packages tree and the source tree a little disconcerting.

Personally, I'd much prefer all the packages for each release to be built fresh. When I first discovered that Pat doesn't actually do this I was quite surprised. I'd always had it in my mind that he'd have one big Slackware.Slackbuild script sitting above all the other slackbuilds, that he'd run to build a full set of new release packages from source.

Anyway, no criticism intended, just expressing my viewpoint.
 
Old 12-09-2008, 06:12 AM   #5
rkelsen
Senior Member
 
Registered: Sep 2004
Distribution: slackware
Posts: 1,748

Rep: Reputation: 159Reputation: 159
Quote:
Originally Posted by GazL View Post
Old binaries are pretty much an unknown quantity and they may work and they may not, or worse yet, they may work but with obscure bugs introduced due to some minor change in a library or header.
In my experience, it's generally only the "system-level" software which may cause problems.

I'm still running some software which was compiled on Slackware 10.0. It works perfectly. There are packages in Slackware which are even older than that.
 
Old 12-09-2008, 06:39 AM   #6
jong357
Senior Member
 
Registered: May 2003
Location: Columbus, OH
Distribution: DIYSlackware
Posts: 1,914

Rep: Reputation: 52
Quote:
Originally Posted by GazL View Post
I fall into the 'recompile it all' camp, myself. The entire Posix/UNIX philosophy seems to revolve around compatibility of source. Old binaries are pretty much an unknown quantity and they may work and they may not, or worse yet, they may work but with obscure bugs introduced due to some minor change in a library or header. It just seems much safer to my mind to recompile the lot. Ofcourse, recompiling with the new tool chain could potentially also introduce obscure bugs, but to my mind keeping everything consistent is worth the risk.

<...>

Owing to the way the Slackware team works, some old packages are carried through to each new release from the previous one. Pat is usually very good at keeping things working, so I trust his judgement on what needs recompiling for a new release and what doesn't, however, its not unusual to find the odd part of the source tree that fails to build after a new release. Though all sources are available, you can't actually recreate a specific slackware release from that releases source tree alone as there may be parts that require a much older release in order to build correctly. I've always found this disconnect between the packages tree and the source tree a little disconcerting.

Personally, I'd much prefer all the packages for each release to be built fresh. When I first discovered that Pat doesn't actually do this I was quite surprised. I'd always had it in my mind that he'd have one big Slackware.Slackbuild script sitting above all the other slackbuilds, that he'd run to build a full set of new release packages from source.

Anyway, no criticism intended, just expressing my viewpoint.
I feel the same way. It's initially more work up front but you don't have to monitor the vitals of numerous packages to make sure everything still jives. Never been a big fan of rolling releases just because you really have to be on your game to make sure everything remains stable.

My hats off to Pat for releasing the way he does. Too much work for me tho....
 
Old 12-09-2008, 06:04 PM   #7
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0
Posts: 3,475

Original Poster
Rep: Reputation: 530Reputation: 530Reputation: 530Reputation: 530Reputation: 530Reputation: 530
I know Pat does not recompile every package with each release. From experience I knew that system level packages directly tied to the kernel or tool chain have to be recompiled.

I had guessed that recompiling all non-stock packages would be safe, but I also guessed that some system level packages might not recompile with the new kernel headers. I have bumped my head a few times with the transition to 2.6.27.7 while testing Current. In that latter case, the prudent approach is don't update to the newest Slackware release immediately --- wait for things to cool and then most of the sources for non-stock packages should have been updated to support the new kernel and tool chain.

I suppose the safe route is when unsure recompile. Yet I don't I want to recompile 130+ packages, therefore I'll take the lazy route and watch for breakage before recompiling.
 
  


Reply


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
Listing Non Stock Slackware Packages Woodsman Slackware 33 09-18-2008 11:11 AM
Where is the modules dir for stock 2.6.18 (Slackware 11) cygnus-x1 Slackware 4 10-16-2006 02:45 PM
Updating Slackware Packages javamdk Slackware 11 03-18-2005 07:37 AM
Updating packages from redhat - insatlling *.hdr packages jomy Linux - Networking 1 01-18-2005 08:36 AM
Upgrading stock 2.4.22 kernel to 2.5.x then to 2.6.6 with existing stock .config file Kyl3 Slackware 8 06-09-2004 05:34 PM


All times are GMT -5. The time now is 04:14 PM.

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