To add to Joe1962's post, when installpkg is called, it only cares about the first 11 lines of the slack-desc file. If you see an official Slackware slack-desc file, you'll see stuff above the actual package description. Look at the slack-desc file for bash from the slackware-11.0 source tree as an examplee:

# HOW TO EDIT THIS FILE:# The "handy ruler" below makes it easier to edit a package description. Line# up the first '|' above the ':' following the base package name, and the '|'# on the right side marks the last column you can put a character in. You must# make exactly 11 lines for the formatting to be correct. It's also# customary to leave one space after the ':'.

|-----handy-ruler------------------------------------------------------|bash: bash (sh-compatible shell)bash:bash: The GNU Bourne-Again SHell. Bash is a sh-compatible commandbash: interpreter that executes commands read from the standard input orbash: from a file. Bash also incorporates useful features from the Kornbash: and C shells (ksh and csh). Bash is ultimately intended to be abash: conformant implementation of the IEEE Posix Shell and Toolsbash: specification (IEEE Working Group 1003.2).bash:bash: Bash must be present for the system to boot properly.Installpkg will only display the stuff with the package name. It will ignore everything above it and below it.

# HOW TO EDIT THIS FILE:# The "handy ruler" below makes it easier to edit a package description. Line# up the first '|' above the ':' following the base package name, and the '|' on# the right side marks the last column you can put a character in. You must make# exactly 11 lines for the formatting to be correct. It's also customary to# leave one space after the ':'.

you could edit /usr/sbin/checkinstall with a text editor as root and change line 1889 from this:echo "$NAME: $line" >> ${BUILD_DIR}/install/slack-descto this:echo $line >> ${BUILD_DIR}/install/slack-desc

but if you did that you would have to add the package name to the slack-desc for every package you made with it

you could edit /usr/sbin/checkinstall with a text editor as root and change line 1889 from this:echo "$NAME: $line" >> ${BUILD_DIR}/install/slack-descto this:echo $line >> ${BUILD_DIR}/install/slack-desc

but if you did that you would have to add the package name to the slack-desc for every package you made with it

Yup, thats what I'm using now, keeps the build data separate from the description.

And about that, I see a lot of the new packages being submitted have the build info included in the description (because it was added to description-pak without the above modification), and then makes the package description longer than 11 lines. Eg:

# HOW TO EDIT THIS FILE:# The "handy ruler" below makes it easier to edit a package description. Line# up the first '|' above the ':' following the base package name, and the '|' on# the right side marks the last column you can put a character in. You must make# exactly 11 lines for the formatting to be correct. It's also customary to# leave one space after the ':'.

Has 19 lines.Even though it may be a hassle to add the packagename: lines manually and use the modification that uelsk8s suggested on checkinstall, the build info get properly separated.Maybe this should be one of the build parameters as well?

You can add that on a script, and just run that script after make, right before checkinstall

Yes I know that.....I'm also using a script to place my build info in.What I'm trying to say is that by just adding the build info to the description-pak without modifying checkinstall makes the build info part of the package description, and not separate.

That example I gave above shows how kdevelop's slack-desc looks like, but it should look like this:

# HOW TO EDIT THIS FILE:# The "handy ruler" below makes it easier to edit a package description. Line# up the first '|' above the ':' following the base package name, and the '|' on# the right side marks the last column you can put a character in. You must make# exactly 11 lines for the formatting to be correct. It's also customary to# leave one space after the ':'.

Personally, I find it more convenient if the build info was readable without having to download the package and explode it. Maybe we could put build info into a separate file instead or add a something like build: in front of the line that will also show up in gslapt/slapt-get?

Personally, I find it more convenient if the build info was readable without having to download the package and explode it. Maybe we could put build info into a separate file instead or add a something like build: in front of the line that will also show up in gslapt/slapt-get?

AFAIK, the build info is copied from the slack-desc file and into a .txt file that is then placed with the package in the repo.So all you have to do is go into the ftp server and read the the file from there.

Personally, I find it more convenient if the build info was readable without having to download the package and explode it. Maybe we could put build info into a separate file instead or add a something like build: in front of the line that will also show up in gslapt/slapt-get?

AFAIK, the build info is copied from the slack-desc file and into a .txt file that is then placed with the package in the repo.So all you have to do is go into the ftp server and read the the file from there.

easuter is indeed correct. The file is called PACKAGES.TXT. It is at the top level of each of the major sub-repos. If you use slapt-get or gslapt to update packages, these files are also on your local box as hidden files in the /home/ftp/pub/veclinux directory. Typing ls -a will yield a list of those files for each source used by slapt-get or gslapt.

easuter is indeed correct. The file is called PACKAGES.TXT. It is at the top level of each of the major sub-repos. If you use slapt-get or gslapt to update packages, these files are also on your local box as hidden files in the /home/ftp/pub/veclinux directory. Typing ls -a will yield a list of those files for each source used by slapt-get or gslapt.

Thanks for pointing this out! It's really helpful. Now I have to modify my checkinstall script to make it compliant...