LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Can slackpkg blacklist just a single program? (https://www.linuxquestions.org/questions/slackware-14/can-slackpkg-blacklist-just-a-single-program-4175590670/)

mfoley 10-03-2016 10:19 AM

Can slackpkg blacklist just a single program?
 
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 (Post 5613190)
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 (Post 5614460)
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 (Post 5614543)
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.


All times are GMT -5. The time now is 08:30 AM.