LinuxQuestions.org - Slackware packaging

- Slackware - Installation (https://www.linuxquestions.org/questions/slackware-installation-40/)

- - Slackware packaging (https://www.linuxquestions.org/questions/slackware-installation-40/slackware-packaging-339692/)

Slackware packaging

Hi group, a quick question.
If I install a product outside of SLACKWARE's native packaging system, can I then remove the older (slackware-installed) packages without causing damage?
I guess I am asking "what exactly is it that removepkg is doing"?

For example, I recently upgraded my SW 9.1 system to XFree86 current version (which is XFree86 V4.5.0, and different to what I believe to SW uses, being X.org), using the install script that came with the software (called Xinstall.sh). Whether this was a desirable upgrade for me to do is another question for another time....

So, if I now use removepkg to remove these obsolete entries that remain in in /var/log/packages, will this actually remove all the software in place, all the X modules currently installed by the XFree installer (which is not what I want, of course). Or will it simply remove the obsolete package entries from his own internal books, and leave the XFree86 moudules in place?

I was prompted to ask this question, by reading Patrick's upgrade Notes (item 8) where he talks about removing obsolete packages.
I am planning an OS upgrade (probably from 9.1 to 10.1), and am carefully reading up on the subject.
Thanks
George

if you run removepkg it will remove every file that the package installed including any files that were overwritten when you installed a newer version.

priller
Yes, that was my guess, and is indeed exactly how I would have expected it to work: that he will remove all files he has has a record of installing, which may well have the same names as those installed outside of SW's packaging system. I should have known better (as the Beatles once sang). I guess one could either uninstall XFre86 (bearing in mind that it neve came with an uninstall script to match the quite nice install script), or perhaps simply removepkg the older X packages, and re-install XFree once again. I'm not sure how much this buys be, apart from keeping the package repository squeaky clean (which is probably desirable, and was probably the way to have done it is the first time around: but let's just say I was a bit new to this, and so was reluctant to remove the "X" that came with the base Slackware 9.1).

Well, I guess there is no harm letting him keep a record of illusory packages, so long as I remember not to manually remove them.
Thanks
George

Does Xinstall.sh ask you for any input?
if not you can use checkinstall program, to pack it. checkinstall is in the 3rd CD /extra
checkinstall ./Xinstall.sh

Does Xinstall.sh ask you to specify an a prefix?
Have you checked?
in most programs the prefix is /usr/local.
anyway if you can specify a prefix, you can create a directory
/tmp/package-XFree86/usr and install it there,
then create a slack-desc file in /tmp/package-XFree86/install
and pack it manually.

OR you can leave it as it is. A few garbage files won't harm your system.

priller, perfect_circle, gbonvehi and friends
I have a Slackware packaging question....

Today I upgraded the main product I use on LINUX (being IBM's DB2 UDB DBMS, upgraded to curret V8.2.2, June 2005). Now I won't bore folks with the gory details, but the IBM product is RPM-based, and S/Ware is not (and so, not "validated" by IBM for this reason (and perhaps other reasons). After long struggle I found that the (undocumented by IBM) trick to success on Slackware is to run rpm2tgz on the supplied rpm's, and use S/Ware's native packaging tools from there, bypassing all IBM's install scripts, etc. IBM's documented workarounds for non-rpm-based distro on its DeveloperWorks website do not work with Slackware (which is to force OFF depedency checking by RPM -ivf --nodeps --force)

This trick has worked perfectly for me, at least once, and tonight I ran UPGRADEPKG --INSTALL-NEW on the 160 packages constituting the DB2 product (in case there were new packages...I suspect there were not, but this is the safest way).
What he did was to make a INSTALL-NEW in every case, leaving the old in the package registry, which I assume is /VAR/LOG/PACKAGES. The object code itself appears to be upgraded correctly. In terms of packages, none were "upgraded"

Clearly my understanding is flawed..I assumed that a newer version would cause the old version to be upgraded (installed afresh) and the old removed.
For example, from the abovenamed directory we see various packages:
IBM_db2xml81-8.1.0-72.i386
IBM_db2jhen81-8.1.0-72.i386 IBM_db2xml81-8.1.0-89.i386
IBM_db2jhen81-8.1.0-89.i386 IBM_db2xmls81-8.1.0-72.i386
IBM_db2jhes81-8.1.0-72.i386 IBM_db2xmls81-8.1.0-89.i386

You can see I have the new (IBM_xxxxxxxx8.1.0-89.i386), and the old, with the "79" suffix. I assumed the newer would upgrade and then remove the older.

What is the correct way to get rid of the old packages, please? (A simple REMOVEPKG? But surely this would remove all files, including the new ones??) And what did I do wrong? Should I have used the oldname/new name options on UPGRADEPKG (ideally, with wildcards...)? Maybe I should have REMOVEPKG all the old ones, and INSTALLPKG the new ones? I believe that this is what the supplied RPM-based script does (which I cannot use, for the reasons explained...)
Here is some of it:
"echo "Updating ..."
for FSET in ${installedpkglist?}
do
grep ^${FSET%-8.1*} ${TMPFILE1?} 1> /dev/null 2> /dev/null
if [ $? -eq "0" ]; then
rpm -e --nodeps ${FSET?} 1> /dev/null 2> /dev/null
fi
"
All help is greatly appreciated. My goal has been to work with DB2 UDB on LINUX (this is my livelihood, IBM database management), and not to necessarily explore the nooks and crannies of S/Ware packaging, but I don't have a tech support group to call on <g>, and I'm not sure if I want to start again and install a validated distro, like RHAT, which would bypass all these peripheral issues. I do have a working system. But I would like to keep his bookkeeping clean, if you know what I mean.
Many Thanks
George

I'm not 100% but it could be because there's no install dir in the rpm's for slackware package manager cant upgrade the packages properly. Could be completly wrong though, I've only used rpm2tgz to install packages, not upgrade.

Where does he keep his book-keeping, of all installed packages, and associated files? I wonder if there is a backdoor, and one can clean it out? I am quite sure that REMOVEPKG will remove the old packages (the ones of version "72", above) , but also all the current files. (This might be want I want, but sounds a bit risky, to do that and then re-INSTALLPKG all the .tgz's.)
Clearly, the /VAR/LOG/PACKAGES is no more than a list, and not a complete package repository.
George

Looking through installpkg it looks like /var/log/packages is where list of packages and their files are kept.

priller - I am not in a position to look at that directory now (am on that OTHER OS!apologies), but I thought it only contained package names, and not file lists...I might be wrong.
What did you mean by the phrase "Looking through installpkg". Is it a script? Does it give clues?
George

Code:

priller@alpha:~/$ more /var/log/packages/bzip2-1.0.2-i486-5 

PACKAGE NAME:    bzip2-1.0.2-i486-5

COMPRESSED PACKAGE SIZE:    136 K

UNCOMPRESSED PACKAGE SIZE:    430 K

PACKAGE LOCATION: /var/log/mount/slackware/a/bzip2-1.0.2-i486-5.tgz

PACKAGE DESCRIPTION:

bzip2: bzip2 (a block-sorting file compressor)

bzip2:

bzip2: Bzip2 compresses files using the Burrows-Wheeler block sorting text

bzip2: compression algorithm, and Huffman coding.  Compression is generally

bzip2: considerably better than that achieved by more conventional LZ77/LZ78-

bzip2: based compressors, and approaches the performance of the PPM family of

bzip2: statistical compressors. 

bzip2:

bzip2: Julian Seward <jseward@acm.org> is the author of bzip2.

bzip2:

bzip2:

FILE LIST:

./

bin/

bin/bzip2

bin/bzip2recover

lib/

lib/libbz2.so.1.0.2

usr/

usr/bin/

usr/bin/bzdiff

usr/bin/bzgrep

usr/bin/bzmore

usr/doc/

usr/doc/bzip2-1.0.2/

usr/doc/bzip2-1.0.2/manual_ovr.html

usr/doc/bzip2-1.0.2/Y2K_INFO

usr/doc/bzip2-1.0.2/LICENSE

usr/doc/bzip2-1.0.2/README

usr/doc/bzip2-1.0.2/README.COMPILATION.PROBLEMS

usr/doc/bzip2-1.0.2/manual.html

usr/doc/bzip2-1.0.2/manual_1.html

usr/doc/bzip2-1.0.2/manual_2.html

usr/doc/bzip2-1.0.2/manual_3.html

usr/doc/bzip2-1.0.2/manual_4.html

usr/doc/bzip2-1.0.2/bzip2.txt

usr/doc/bzip2-1.0.2/manual_abt.html

usr/doc/bzip2-1.0.2/CHANGES

usr/doc/bzip2-1.0.2/manual_toc.html

usr/lib/

usr/lib/libbz2.a

usr/man/

usr/man/man1/

usr/man/man1/bzip2.1.gz

usr/man/man1/bzdiff.1.gz

usr/man/man1/bzgrep.1.gz

usr/man/man1/bzmore.1.gz

usr/man/man1/bzip2recover.1.gz

usr/include/

usr/include/bzlib.h

install/

install/doinst.sh

install/slack-desc

priller - thanks again. You know, I only ever saw package names there, and not the sub-directories.
My guess, then, is that this IS his package repository, and this is where PKGTOOL looks when you ask to view a list of files in packages.
What do you think?
In which case, it seems that this is the back door, that one could remove the directories from here, and that effectively removes the packages from his "books", while at the same time leaving the current files in place?
Thanks
George
P.S It's still unclear to me why UPGRADEPKG --INSTALL-NEW didn;t do this removal. Perhaps someone else will chime in.....

They aint sub directorys, just files containing a list of files in each package.

priller - I got you. I never actually looked in the files under /PACKAGES. What you have printed is exactly what PKGTOOL displays, when you select yo View the list of files in a package.
It seems to me that this is where he store the list of files associated with a S/Ware package, and this is what is used to remove files associated with a package.

Then in this case, one could just delete the "old" package names from here, from/VAR/LOG/PACKAGES and - in essence - achieve a REMOVEPKG of these obsolete packages, without disturbing the correct files which are currently in place (as a result of the most recent UPGRADEPKG).

Do you agree?

George

See no reason why you couldn't just delete the file.

priller
Thanks again. It does look that way, that simply deleting the file would be the "back door" to manipulating his "books". And the package would presumably no longer show up in PKGTOOL, etc?
Thanks for walking me though this.
George