Okay............If I understand you correctly, you're looking for something that will give you a dependency check of sorts..............plug in a filename name and it'll tell you which Slackware package is needed........

However, this method won't work when plugging in a name of a symlink (or a renamed file) as the MANIFEST file gives you an exploded list of the files stored in each package, whether source or slackpack..........but slackpacks don't store the symlinks in the package, they create symlinks after installing the stored files using the doinst.sh script, as well as renaming files...........

Basically, you would have to not only look at the filenames inside the packages, but read and analyze any doinst.sh scripts inside each package (if the package has one)..............and to do that, you would need to have a local mirror of the slackware tree....................it could probably be done using the first and second installation CDs.................Unless another list was created containing the symlinks and renamed files for every Slackware package............

Hmmm........this is beginning to sound interesting.......

Okay, here's a quick and dirty solution for searching through the MANIFEST files to find the file you're looking for and the package it will be found in.......

First grab the MANIFEST.bz2 files from a Slack mirror..........for each Slack version there should be a MANIFEST file in the directories extra. pasture, patches, slackware, source, testing. (NOTE: The Slack-current tree won't have a patches directory.).........Then run the following command on whichever MANIFEST file you choose, replacing FILENAME with the file you're looking for: The '\<' in front of the search term is an extended regular expression metacharater that means what follows is the beginning of a word, and the '$' after the search term means to look at the end of the line..............this will help filter out the majority of false positives.....and you must use 'egrep' to use the '\<' metacharacter (plus 'egrep' is supposed to be a little faster than 'grep')..................

For example, here's the ouput when searching bzip2 in the slackware-10.0/slackware/MANIFEST.bz2 file:

That seems interesting. I'll have to look at that tomorrow, though, as it's getting late here in Deutschland. Does that work if FILENAME$ is not part of the package name? Is that case sensitive or any other caveats?
maybe an 'incomplete' search (without looking in the doinstall.sh) would still be useful if the search string was general, since some/most symlinks have a similar name. However, an exhaustive search, seems like the only dependable way to resolve a dependency if it can be done with a Slackware package.

I'm not too sure what you mean by not being part of the package name. This will only find the strings in the MANIFEST file, which is merely a listing of what files can be found in a package............If you wondering about whether you need to know part of the package name to make it work, the answer is No.........

The search is for the filename, but how it works is the first 'egrep' command will list all the lines with the word "Package:" along with any lines that may include the search term (filename) you are looking for, listing each in the same order it finds it............while the second 'egrep' command will again look for the desired filename, but also include the line above it from the output of the first 'egrep' command, which _should_ be the name of the package.......

Remember that the search is for any lines containing the search term at the end of each line, which will exlcude the names of packages..............It's the second 'egrep' command which will include any line above the matching line from the output of the first 'egrep' command, which will hopefully be the name of the package

Yes, it's case sensitive.........If you want a case insensitive search, just add the switch '-i' right after each 'egrep' command and before the search term..................As for any other limitations, you will need to use the whole filename for the search term, or you can use extended regular expression pattern matching (not wildcard globbing) to expand the search.............Also, see my post above (post #46) for a quick insight on what will be missing in the search..........and there may be other unforseen complications........I only came up with this on the spur of the moment without doing any real testing of search terms..............like I said at the beginning, a "quick and dirty solution"............

The orphan/renegade search script is updated. It has taken some time to get this finished, mostly due to some bug-mud I fell in concerning the declare -a that for instance the Advanced Bash-Scripting Guide says should speed up the use of arrays. It does speed it up, but it also makes the arrays unable to contain elements with spaces and parenthesis and stuff. Pretty odd, I'd say. The script should be fairly ready for use by now, but it can of course not be used blindly - you have to check the results! There are mainly two classes of false-positive orphaned files: (1) files generated by other programs, often containing configuration, and other, data, and (2) files in /var. The /var directory should perhaps be completely excluded from the search. Also, /bin/bash is of course a false-positive, since it is renamed from the package name /bin/bash2. Other possible false-positives are the man pages, since they sometimes are gzipped, sometimes not. On my system they do not show in a search, though, so it seems ok.

The most important update is the search for orphaned directories. This will first locate the directories on the file system that are not explicitly seen in /var/adm/packages/*. The created list of orphaned directories is collapsed to be as short as possible. The search for orphaned files is then adapted to exclude the orphaned directories. This means that the orphaned files in an orphaned directory will not be listed since they are included in the orphaned dir. This gives a performance penalty by a factor of about 2 compared to the former version, but it is a nice feature that I didn't want to leave out. It searches the 4 gigs of system files (/usr /bin /sbin /opt/kde and so on) on my computer in 10 minutes which is still bareable.

If you look carefully at the code, you might object (to a lot of things, but perhaps the thing I'm after here) that it should loop over the contents in $PACKAGEDIRS instead of $(grep -xf "$PACKAGEDIRS" "$DIRTREE") in the search for orphaned files. However, then it will follow symlinks, and in some cases erroneously classify the files seen under the symlinked directories as orphans.

There is also a new --quiet option which will disable the logfile. It could also be disabled by just setting LOGFILE="".


Now to something completely different. You know all those .new files that you find in for instance /etc after an update? It can be quite boring to locate all these and rename them, so I whipped up a script (oh, really? ) to help me in this. It also backs up the older scripts, appending a .old, up to a maximum of two old versions. Here it is:
Cheers

hey thegeekster

Can I post your lspkg, pkginfo and whichpkg scripts in my site? They're very useful scripts.

Sure............but check your email first..........

I'ved added legal disclaimers for anyone who may want to post these pkg scripts above on their website. So feel free to do so with my blessing.......

Also modified the code to reflect my newest style of bash programming (no new features, just a different way of coding)......


---thegeekster

Will have your scripts in my site with the next update

Hello again,

I've made an important upgrade of my orphan search script above. After searching for orphans using the info in /var/adm/packages, the script now also checks the (apparent) orphans found against the contents of the install scripts in /var/adm/scripts.

Cheers

May I suggest that this post be made sticky? At least the newbies to this forum would see it and not only stumble on it (if they ever do).

Hello there,

I just wanted to alert any fans of my orphans script - if there are any - that I've posted another update in the original post. This takes care of one or two annoying bugs; nothing dangerous, but still. (Well, even though the bugs weren't dangerous, it is very difficult to make this kind of script benign. If you aren't careful you'll ruin stuff.) And for those interested in the various Linux (and maybe UNIX too for that matter) string comparing/searching tools, I can tell you that I've managed to speed the script up by a factor of 3-4, as compared to the former version, by using the command comm instead of any of the grep siblings.

Cheers!