Latest GNU software in Slackware
 

I just came across about the new release of GNU ed from gnu.org, which is currently ed 1.2 at Feb 05, 2009.

But in slackware-current, it's still having version 0.9, where version 1.0 stable is already released in Nov 2008

1)I would like to know is this mean that not all program in the latest slackware is up to date ?
2)Anybody know is this frequent happen to other program in Slackware?
3)Based on what requirement are program in Slackware being added with the latest ?

Just like to know more about Slackware, hope any experience slack user could give some idea, thanks in advanced.

"The Man" cares more about stability and security than shiny and new, but you are free to experiment if there is a new feature you just can't live without. In many cases the best version is not necessarily the newest one.

I need cpio because tar drops file attributes (permissions, etc.) randomly when the file names are very long (or when the archive is very large. I can't recall). I cannot afford for this.

However, the old cpio comes from Slackware does not support large file. I did submit a SlackBuild script and expressed several times the above problem to The team. Don't know what the security reason is for which cpio shall not be upgraded.

The latest entry for cpio I found on Slackware changelog is this one on the Slackware 12.0 Changelog:

You can go for bleeding edge, but you're the one who'll be left bleeding.

sloganyart, do you really use 'ed'? In all my years at this, I've only seen one script which called the ed program -and that script was from 1999 or so...
'ed' and many other small programs were recently broken out from what used to be a single 'bin' package. This makes it easier for you to upgrade single programs if you want. Simply grab the sources for the latest (greatest?), grab the SlackBuild for the normal version and edit it tochange the bersion number and build a package of the newer version and upgrade.
Of course, there can always be issues which you are not aware of -as shown by the notes in the ChangeLog about cpio. Even then, one could always package the newer version of cpio and change the name of the binary and the package so that it could co-exist with the version which comes with slackware. Simply calling the cpio binary with the new name will let you use it when needed. Or, vice-versa, you could change the name of the old version and edit the mkinitrd script to call that version. Or, if you don't even use an initrd, just upgrade to the newer version -the incompatibility with the kernel has only to do with initrd's created using cpio.

I'm not a very experienced Slackware user (I would say I'm a medium-range type of user with Slackware since 10.2) and here is my personal understanding of software upgrade in Slackware.

a) First priority is stability, so any upgrade would be considered in regard to whether it fixes some bugs and/or introduces new features. I suspect that a newer version introducing new features would be acceptable only in the early phase of the -current development cycle to allow some testing of these features.
Conversely, when "The team" thinks it's getting close to a new release, every change is analyzed for the benefit it brings and I think the benefit here is only to fix known bugs.

b) "The team" working on -current has most probably a roadmap to the next stable release and may not be focused on tracking every upgrade for software not involved in the current roadmap. So it may not hurt to notify the team of the availability of a new version (most probably with explanation about your reason you would like the upgrade)

c) If an upgrade breaks anything (ex: cpio, see my previous post), the first thing to do is to downgrade the software to the latest known working version and look at the problem later. If nobody looks at the problem nor provides suggestion on how to solve it, then no change.

Thanks gegechris99 and gnashley, yours' reply really answer my doubt. In fact I'm not really needing the 'ed' program, just curious why it's not updated and am wonder is there a valid reason behind this or the slackware team miss look that. And now seems there is a valid reason for this, so you guys basically answer my doubt.

I'm glad that things are really being taken good care in Slackware development, as I like this distro, that's why come the curious to know more.

Thanks guys and hope that guanx has his question answered as well :)

I've just built and tested the latest 2.9 release of cpio, and it seems fine here based on very casual testing. Assuming no problems are found, I'll put it in my staging area for future upgrades, and from there, it's up to Pat.

Heh... I was doing the same :-) Our way of creating initramfs should not be affected by cpio changes. But a test with a new installation and initrd will show if that is correct.

Eric

Very strage. Before release of Slackware 12.0, cpio had grown from 2.5 to 2.7. So if there is a bug, it must be introduced between 2.5 and 2.7.

The only major difference I can observe between cpio 2.5 and post-2.5 versions is that the hexdecimal representation of numbers in the posix header (-H newc) changed from lower case to upper case.

Another one is that the stored inode numbers in the headers are also different occasionally. Version 2.7 of cpio sometimes store inode numbers larger by one than 2.5 and 2.9 do. e.g. For my test file "cpio-2.7/lib/lchown.h", cpio-2.7 stores the inode number 385765 while both 2.5 and 2.9 stores 385764. The result of "ls -i" shows cpio-2.7 is correct.

So I wonder from where the "bug" comes.

P.S. The two persons mentioned in the Changelog seem to be related to documentation correction, not to code (if I'm not mistaken). So I cannot ask them for testcase.

Thank you! Rworkman.

I have been using cpio-2.9 since Slackware-12.1. It never failed. However, I did not use the in-image initramfs. I always use an initrd. But I think the two share the same code for cpio.

Hello! Eric, the Changelog says it was the initramfs, not initrd, thought I don't know if the latter was also broken.

Tell you something... Modern-day initrd ( by default /boot/initrd.gz) is actually an initramfs!

Eric

PS: I tested cpio-2.9 by letting mkinitrd generate a new /boot/initrd.gz (mkinitrd calls on cpio for this) and the kernel booted fine using that file as an initramfs.

There are two ways to boot with an initial ramdisk. One is to pack the filesystem into the kernel image, the other is to use an external initrd file. I believe they share the same low level code, but any difference is still possible in case of bugs.