Can slackpkg blacklist just a single program?

mfoley · 10-03-2016, 10:19 AM

I've modified a single program: kcheckpass, in the kde-workspace package. I don't want to blacklist the whole package, but I don't want my modified program to get clobbered on the next upgrade. Is there a way to blacklist a single component within a package?

ponce · 10-03-2016, 10:25 AM

no, if you want to handle this via slackpkg you have to blacklist the package: slackpkg won't handle anything about the content of the packages, it uses the pkgtools utilities (installpkg, upgradepkg, etc.) for installing/upgrading.

alternatively, you can make the file immutable with chattr

Code:

chattr -i /usr/lib$LIBDIRSUFFIX/kde4/libexec/kcheckpass

so that an upgrade of kde-workspace won't overwrite it.

mfoley · 10-03-2016, 01:16 PM

Or, could I simple `chmod a-w /usr/lib$LIBDIRSUFFIX/kde4/libexec/kcheckpass`, rather than using chattr? I've used chattr, but not much and when I need to ultimate modify such a file I always forget that months/years ago I chattr'ed it.

bassmadrigal · 10-03-2016, 01:33 PM

You can still remove a file that has the write permission removed. Try it yourself.

Code:

touch test
chmod -w test
rm test

It will ask if you want to remove a write-protected file, and you can hit the y to continue to remove it. removepkg would force that using the -f option of rm.

mfoley · 10-03-2016, 04:49 PM

Good point! Thanks.

BCarey · 10-05-2016, 07:49 PM

Quote:

Originally Posted by ponce

no, if you want to handle this via slackpkg you have to blacklist the package: slackpkg won't handle anything about the content of the packages, it uses the pkgtools utilities (installpkg, upgradepkg, etc.) for installing/upgrading.

alternatively, you can make the file immutable with chattr

Code:

chattr -i /usr/lib$LIBDIRSUFFIX/kde4/libexec/kcheckpass

so that an upgrade of kde-workspace won't overwrite it.

Shouldn't that be

Code:

 chattr +i filename

?

a4z · 10-06-2016, 12:31 AM

the 'common' way to solve this is to put the program on a place that is before /usr/bin in you $PATH,
that is usually /usr/local/bin, which is there for such and similar reasons.
than it doesn't matter if the original binary becomes overwritten by an update. and you can easily switch both versions, if this is ever needed.
putting things to /usr/local/ will also allow you to package and manage your software via the available pkg tools

ponce · 10-06-2016, 12:39 AM

Quote:

Originally Posted by BCarey

Shouldn't that be

Code:

 chattr +i filename

?

yes, I accidentally wrote how to do the opposite (removing the immutable attribute), thanks for pointing it out!

mfoley · 10-06-2016, 09:30 AM

Quote:

Originally Posted by a4z

the 'common' way to solve this is to put the program on a place that is before /usr/bin in you $PATH,
that is usually /usr/local/bin, which is there for such and similar reasons.
than it doesn't matter if the original binary becomes overwritten by an update. and you can easily switch both versions, if this is ever needed.
putting things to /usr/local/ will also allow you to package and manage your software via the available pkg tools

That is an excellent idea!! I'll try it. That would save me from having to either chattr the file, or move it elsewhere before doing the update. The problem with the chattr solution is that I still want the original to get updated because my kcheckpass script will run the 'real' program for local users. So, if I put my replacement in /user/local/bin, my script can still run /usr/lib64/kde4/libexec/kcheckpass explicitly. This solution lets me substitute the command while still retaining the original's upgradeability!

LATER ...

Although a great idea, it doesn't work in this case. Apparently the system calling program, kscreenlocker_greet, looks for kcheckpass explicitly in the /usr/lib64/kde4/libexec directory. I had to move it back to get it to work.