The purge error with the customize reconfigured debian package - linux

I try to build a debian package which to replace the lirc initial script
I have been referenced Building a preconfigured debian package, How to use dpkg-divert to temporarily remove/replace symlink when package is installed? and Debian Policy Manual Appendix G
But it has the problem with removes the package.
Here is the install prompt and it can be installed successfully
Setting up mylirctest (0.0.1) ...
Configuration file '/etc/init.d/lirc'
==> Deleted (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** lirc (Y/I/N/O/D/Z) [default=N] ? Y
Installing new version of config file /etc/init.d/lirc ...
Processing triggers for ureadahead (0.100.0-16) ...
There is the problem when progress my package
(Reading database ... 148259 files and directories currently installed.)
Removing mylirctest (0.0.1) ...
Removing 'diversion of /etc/init.d/lirc to /etc/init.d/lirc.disable by mylirctest'
dpkg-divert: error: rename involves overwriting `/etc/init.d/lirc' with
different file `/etc/init.d/lirc.disable', not allowed
dpkg: error processing package hdstation (--purge):
subprocess installed post-removal script returned error exit status 2
Errors were encountered while processing:
mylirctest
Here is my preinst file:
#/bin/sh
set -e
dpkg-divert --package mylirctest --add --rename --divert /etc/init.d/lirc.disable /etc/init.d/lirc
The postrm
#!/bin/sh
set -e
dpkg-divert --package mylirctest --remove --rename --divert /etc/init.d/lirc.disable /etc/init.d/lirc
Is there any wrong with my postrm?
And How can I disable the prompt message when install my deb package?
Many thanks

It's a year old question, but I've faced the same issue and fixed it, so here is the answer in case someone need it:
To properly restore the file using dpkg-divert in postrm you have to delete current file first, like this:
#!/bin/sh
set -e
rm /etc/init.d/lirc
dpkg-divert --package mylirctest --remove --rename --divert /etc/init.d/lirc.disable /etc/init.d/lirc

There is a major update available in the Debian experimental channel. It's a breaking update with completely new configuration. That said, the old lirc packaging bug exposed here should be fixed in the updated package (0.9.4b)

Related

Remove perl package completely

I am trying to uninstall the old perl package and install a new package. I used rpm -e to uninstall the old package. I could still see the below files after uninstalling. How can i completely remove the perl package from my server. It runs on OEL 6.10. And when I do "perl -v" , I could see 5.30 version as output, even after uninstalling perl.
/opt/CWx/perl
/opt/CWx/modules/installed/Module-Build-0.4005/inc/Perl
/opt/CWx/modules/installed/Perl-OSType-1.003/blib/lib/Perl
/opt/CWx/modules/installed/Perl-OSType-1.003/blib/lib/auto/Perl
/opt/CWx/modules/installed/Perl-OSType-1.003/blib/arch/auto/Perl
/opt/CWx/modules/installed/Perl-OSType-1.003/lib/Perl
/opt/CWx/modules/Module-Build-0.4208/inc/Perl
/usr/src/kernels/2.6.32-754.11.1.el6.x86_64/tools/perf/scripts/perl
/usr/src/kernels/2.6.32-754.6.3.el6.x86_64/tools/perf/scripts/perl
/usr/src/kernels/2.6.32-754.2.1.el6.x86_64/tools/perf/scripts/perl
/usr/local/share/perl5_old/Perl
/usr/local/bin/perl
If you want to know which package installed a file you can use the command:
rpm -q --whatprovides [filename]
For example, for the first file in your list:
rpm -q --whatprovides /opt/CWx/perl
None of the files you list are in locations which are used by the standard Perl RPM on a RedHat-based system. You will, I expect, find that they are either installed by a completely different package or not installed by a package at all.
And that will also explain why you can still access Perl. Those files include other versions of the Perl compiler and I bet that whoever installed them also changed the PATH so that you have access to at least one of them.
If you want to know which Perl installation is responding to your commands, just run this:
which perl

Install TCP Wrappers in Slackware 14.2

How to install TCP Wrappers using the appropriate package manager? When I run pkgtool, I can see in the list that tcp_wrappers is included tcp_wrappers-7.6-x86_64-1. I want to install it.
I tried the command below, with no luck.
installpkg tcp_wrappers-7.6-x86_64-1.tgz
Whenever I run the command above, it says
Cannot install, file not found.
So I navigated to /var/log/packages, where the list of Slackware packages are listed and I found there tcp_wrappers-7.6-x86_64-1 file. So what I did is:
mv tcp_wrappers-7.6-x86_64-1 tcp_wrappers-7.6-x86_64-1.tgz
installpkg tcp_wrappers-7.6-x86_64-1.tgz
The prompt message is :
Verifying package tcp_wrappers-7.6-x86_64-1.tgz
gzip : stdin : not in gzip format
Installing package tcp_wrappers-7.6-x86_64-1.tgz:
PACKAGE DESCRIPTION:
WARNING: Package has not been created with 'makepkg'
Package tcp_wrappers-7.6-x86_64-1.tgz installed.
After, I verified whether the tcp_wrappers is already installed using the commands below, with no luck.
rpm -q tcp_wrappers
rpm -q tcp_wrappers-7.6-x86_64-1
rpm -q tcp_wrappers-7.6-x86_64-1.tgz
It just say:
package tcp_wrappers is not installed
package tcp_wrappers-7.6-x86_64-1 is not installed
package tcp_wrappers-7.6-x86_64-1.tgz is not installed
what shall I do?
If it is in /var/log/packages, then it's already installed. Files in this directory are simple text files with package description, list of installed files etc. Try for example:
less /var/log/packages/tcp_wrappers-7.6-x86_64-1
On my box it shows:
PACKAGE NAME: tcp_wrappers-7.6-x86_64-1
COMPRESSED PACKAGE SIZE: 77.0K
UNCOMPRESSED PACKAGE SIZE: 340K
PACKAGE LOCATION: /usb-stick/slackware64/n/tcp_wrappers-7.6-x86_64-1.txz
PACKAGE DESCRIPTION:
tcp_wrappers: tcp_wrappers (TCP/IP daemon wrapper library and utilities)
tcp_wrappers:
tcp_wrappers: With this package you can monitor and filter incoming requests for
tcp_wrappers: network services for access control, and detection things like host
tcp_wrappers: name spoofing and host address spoofing. Nearly all the network
tcp_wrappers: daemons on Slackware are "wrapped" using this library, and most
tcp_wrappers: daemons in /etc/inetd.conf use tcp_wrappers' tcpd wrapper daemon.
tcp_wrappers: If you plan to do much networking, you will need tcp_wrappers.
tcp_wrappers:
tcp_wrappers: tcp_wrappers was written by Wietse Venema.
tcp_wrappers:
FILE LIST:
./
install/
install/slack-desc
usr/
usr/doc/
usr/doc/tcp_wrappers_7.6/
usr/doc/tcp_wrappers_7.6/BLURB
usr/doc/tcp_wrappers_7.6/CHANGES
usr/doc/tcp_wrappers_7.6/DISCLAIMER
usr/doc/tcp_wrappers_7.6/README
usr/doc/tcp_wrappers_7.6/README.NIS
usr/include/
usr/include/tcpd.h
[ cut ]
rpm is RedHat tool. It will not show this package as installed, because pkgtool used by Slackware is not related to rpm in any way - it doesn't update rpm package database. rpm is installed in Slackware only for installing rpm packages, not to manage packages installed by native pkgtool.
To test, whether the packet has been installed or not, one should simply issue the command:
slackpkg search tcp_wrappers
Output will be (e.g. on Slackware 12.0)
The list below shows all packages with the selected pattern.
[ installed ] - tcp_wrappers-7.6-i486-1
The `slackpkg' allows to install, remove, list etc packets in the system. Please see the get the help option.
As for TCP_wrappers, it is included in Slackware long ago, I think

Conflicts with file from package filesystem-3.2

After repeated attempts and trying to google this issue I'm stuck and am looking for help from my fellow stackers.
Following the wiki from tcadmin I have to run the following commands
wget http://www.tcadmin.com/installer/mono-2.11.4-i386.rpm
yum -y install mono-2.11.4-i386.rpm --nogpgcheck
/opt/mono-2.11.4/bin/mozroots --import --sync --quiet
/opt/mono-2.11.4/bin/mono --aot -O=all /opt/mono-2.11.4/lib/mono/2.0/mscorlib.dll
for i in /opt/mono-2.11.4/lib/mono/gac/*/*/*.dll; do /opt/mono-2.11.4/bin/mono --aot -O=all $i; done
when I get to the yum part it fails and outputs this error.
file / from install of mono-2.11.4-bi.x86_64 conflicts with file from package filesystem-3.2-18.el7.x86_64
Most sites and places suggest using an override or force command but this sounds stupid and will probably cause issues down the road for myself and the system.
I have flagged a ticket with the company that supplies the wiki about this issue but I'm yet to have a reply.
Another suggestion was to extract the rpm and move the files one by one but this is quite time consuming..
The ticket was responed to with the following;
It is safe to force install because all files are placed in /opt/mono-2.11.4 but there is a bug with mono on centos 7 that prevents tcadmin from working correctly.
For anyone else who happens upon this thread, I'm pleased to report that while I didn't encounter this error installing mono (that was a whole other process) I did encounter it while trying to install TCAdmin itself, but I was able to complete the installation of TCAdmin on CentOS 7 after using rpmrebuild to modify the spec.
Simply install rpmrbebuild, run rpmrebuild -pe {packagename}.rpm, scroll down to the %files section and remove the lines for any offending directories (in my case, the '/' and '/home' directories), save and quit, press y, and note the result location. In my case, it was /root/rpmbuild/RPMS/noarch/{packagename}.rpm.
Traverse to that directory and run yum -y install ./{packagename.rpm and it will install without a hitch.
The same should also apply to any other packages that return the conflicts with filesystem error. Just adjust the package names in the above examples accordingly.
*Thanks to the venerable Ahmad Samir for pointing me in the right direction with his post in this thread.
I had the same issue trying to install Fluentd agent on CentOS 7:
(venv)[user#machine01 tmp]$ sudo rpm -ivh td-agent-2.1.1-0.x86_64.rpm
warning: td-agent-2.1.1-0.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID a12e206f: NOKEY
Preparing... ################################# [100%]
file /opt from install of td-agent-2.1.1-0.x86_64 conflicts with file from package filesystem-3.2-18.el7.x86_64
I wouldn't say that downgrading your whole OS is the solution. Maybe an elegant workaround would be to rebuild the .rpm file in order to avoid those file systems which are making conflicts. You can do this by modifying the spec file with rpmrebuild command.
However, if you trust the software you are about to install or you want to try if works no matter what, then an easier (and faster) workaround is to force the rpm installation. That's what I did ...
(venv)[user#machine01 tmp]$ sudo rpm -ivh --force td-agent-2.1.1-0.x86_64.rpm
warning: td-agent-2.1.1-0.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID a12e206f: NOKEY
Preparing... ################################# [100%]
Updating / installing...
1:td-agent-2.1.1-0 ################################# [100%]
adding 'td-agent' group...
adding 'td-agent' user...
Installing default conffile...
prelink detected. Installing /etc/prelink.conf.d/td-agent-ruby.conf ...
Configure td-agent to start, when booting up the OS...
...and it worked for me
(venv)[user#machine01 tmp]$ sudo systemctl start td-agent.service
(venv)[user#machine01 tmp]$ sudo systemctl status td-agent.service
td-agent.service - LSB: td-agent's init script
Loaded: loaded (/etc/rc.d/init.d/td-agent)
Active: active (running) since vie 2014-12-12 09:34:09 CET; 4s ago
Process: 17178 ExecStart=/etc/rc.d/init.d/td-agent start (code=exited, status=0/SUCCESS)
...
Hope it helps
This is an inherent issue with centos 7.
Going back to centos 6 fixed it.

A mess with different Perl installs

I tried to upgrade Perl and put my computer into a complete mess
I am currently running RHEL6.5, 64bits, and this is the thing:
I had perl-5.10.1 installed, and working nice. this came installed,
and I could see it from yum
I wanted to install Padre, an Perl IDE, but that required at least v5.11 [I was so close! :( ]
There were no newer version for Perl in the repos that I have access to (and I have a limitation that I can't add new repos)
I got approval from my boss to download perl-5.20 .0 from www.perl.org and tried to install it
... and the mess begins!
First I installed the new perl with my own id, and that pushed perl to somewhere under my home dir
I tested with 'perl -v' and could see that my env was pointing to the newer install, however, yum never recognized it (not really a problem)
When I tried to install Padre, seems somehow it had the hardcoded the original perl (from /usr/bin) and still claiming for something as newer as 5.11.
Trying to fix it, I did installed the new perl again, now using root, to make it push perl under /usr tree ... it installed, but pushed perl to /usr/local/bin, instead of /usr/bin
So again, I had one more perl install but Padre still looking for the one on /usr/bin
I give up about Padre, and deleted the files related to it, as well as the perl installed on my home dir, however a couple of perl scripts that I had already coded now are throwing errors like:
perl -cw "xmltest.pl" (in directory: /home/myid/scripts/xmltest.pl)
perl: symbol lookup error: /usr/lib64/perl5/auto/Data/Dumper/Dumper.so: undefined symbol: Perl_Istack_sp_ptr
Compilation failed.
... and Data::Dumper in not the only one ... every time I disable one of the modules, another one hangs in the same, or similar way
From what I read about this, seems that this issue is related to modules that were originally installed for one perl version, and are being called by another, however, I already forced the modules that I use to be reinstalled directly from CPAN, and they still failing
Question: How can I, safely, get free from this current perl installs, and perform a new clean install be able to use it w/o these versions conflicts?
My major concern are about the numerous apps that I have that depends on Perl, and I my not broke then on a uninstall
Any help will be much appreciate.
You should:
cleanup
clean (comment out) your ~/.profile from any unwanted paths, and so on
clean any new perl installation from your $HOME (move to safe place for sure)
in short, try return your environment into previous working state
relog, (logout, login)
repair your system perl. Thats mean,
read #Sam Varshavchik's answer
reinstall it from your distribution, using your package manager (5.10).
this step should overwrite the mess you caused.
test it !
don't continue until youre ensured, everything working right as before.
Lesson learned: never overwrite your system perl
learning
read thru perlbrew.pl
repeat previous step once again, especially with the
the homepage
http://perlbrew.pl/Perlbrew-and-Friends.html
https://metacpan.org/pod/App::perlbrew
https://metacpan.org/pod/perlbrew
installing perlbrew
run the installation command \wget -O - http://install.perlbrew.pl | bash
should finished without errors
follow the instructions how to modify your startup file e.g. ~/.profile or such... (you need to add one line to the end)
check your ~/perl5/perlbrew/bin should contain prelbrew and patchperl
relog
setup new perl, run
perlbrew init #init environment
perlbrew available #show what perl you can install
perlbrew install 5.20.0 #will take few minutes - depends on your system speed
perlbrew install-cpanm
perlbrew list #check
perlbrew switch perl-5.20.0 #activate newly installed perl 5.20
Check your installation
in the ~/perl5/perlbrew/bin you should have 3 scripts: prelbrew , patchperl , cpanm
perl -v should return 5.20
type cpanm - should return ~/perl5/perlbrew/bin/cpanm
You're done.
CPAN modules
You can install new modules with cpanm, like:
applications
cpanm cpan-outdated
cpanm App::Ack
cpanm Unicode::Tussle
cpanm Perl::Tidy
cpanm Perl::Critic
collections
cpanm Task::Moose
cpanm Task::Plack
cpanm Task::Unicode
modules
cpanm Path::Tiny
cpanm Try::Tiny
cpanm JSON
cpanm YAML
etc...
Check the ~/perl5/perlbrew/perls/perl-5.20.0/bin/ for new commands
You will need update your own perl script's shebang line to
#!/usr/bin/env perl
I hope don't forget anything, maybe other more experienced perl-gurus will add/edit/correct more.
Anyway, in the reality the steps 5,6,7 are much easier as sounds (by reading this) and could be done in few minutes.
On rpm-based Linux distributions, you should never install system software manually, like this, by trying to compile and build it yourself. RHEL's package management tool, rpm, performs an important function of keeping track of dependencies between packages, and prevent package conflicts.
The errors you showed are precisely the symptoms of a corrupted system Perl installation, and rpm exists precisely to avoid this sort of thing happening. Manually building and installing random tarballs completely bypasses the safety net that rpm provides.
There's no cookie-cutter recipe for recovering from a corrupted system install of a critical system rpm like perl, but in general:
1) run "rpm -q" perl, this will show you the exact version of the perl rpm package that rpm thinks should be installed.
2) go to the RHEL installation media/directory, verify that it contains the same perl-.x86_64.rpm package. If you previously installed RHEL updates, it's possible that you already updated perl, so look for the version that rpm tells you have installed in the RHEL update directory, and verify that you have the correct rpm package.
3) Execute:
rpm -ivh --force perl-<version>.x86_64.rpm
This will reinstall the original perl RPM package that was previously installed. Your problem is not only that you have extra versions of perl installed, but that it's likely that some of your custom perl builds have clobbered the system perl package, and uninstalling them won't help, you have to reinstall the system perl.
4) In RHEL, many perl modules are installed as separate packages. The above process should be used to reinstall every perl rpm package that you have installed. Execute:
rpm -q -a | grep '^perl'
This will give you a list of all Perl packages you have installed. You will need to repeat this procedure for every Perl rpm package.
It's not a 100% guarantee that this will fix everything, there could be other things wrong too, but this is a good first step towards recovery.
What I have done:
From #Sam-Varshavchik answer:
Found the previous perl rpm in my yum cache, and installed ...
rpm -ivh --force perl-<version>.x86_64.rpm
Checked for others "perl*" previously installed packages ... there were +260 so saved it in a file rpm -qa "perl*" > /tmp/perl.pkgs
With +260 packages to install, I realized that do it manually would take too much time, so it was time to put some ksh skills in practice ...
I checked at my yum cache and found ~130 of the +260 packages, so
took out from the list the base perl package (that I already have installed);
for those in the cache, I decided to install then with rpm, in the same way as the base package;
for those that I did not have handy, I used yum, which would download and do the same
of rpm, so ...
CACHE="/var/cache/yum/x86_64"
for perlpkg in $(cat /tmp/perl.pkgs)
do
FILE=$(find $CACHE -name "${perlpkg}.rpm")
if [[ ${FILE} != "" ]] ; then
rpm -ivh --force ${FILE}
else
yum -y reinstall ${perlpkg}
fi
done
From #jm666:
Installed perlbrew (was able to got it from my auth repos, so got it using yum) and using perlbrew, installed 5.20.0 localy
TODO: Didn't got any additional modules and neither Padre yet ... need to learn more about the way perlbrew works and isolate the installed version away from the system perl
Once again, thanks #Sam-Varshavchik and #jm666 for your support ang guidance

Net-SNMP perl module won't make

Firstly, I am using a Beaglebone Black with the Angstrom distribution.
My mib2c program for net-snmp won't work and give the following error:
ERROR: You don't have the SNMP perl module installed. Please obtain
this by getting the latest source release of the net-snmp toolkit from
http://www.net-snmp.org/download/ . Once you download the source and
unpack it, the perl module is contained in the perl/SNMP directory.
See the README file there for instructions.
So I go to /net-snmp/perl/SNMP and run
perl Makefile.PL
make
Now it gives me this error:
make: *** No rule to make target `/usr/lib/perl/5.14.2/ExtUtils/typemap', needed by `SNMP.c'. Stop.
Ok, so I know that the ExtUtils module must be installed (which it is), but all that I have in that folder are .pm files. When I run them using perl nothing happens. I've also tried to look for the files online (after I create a typemap file there it asks for a xsubpp file aswell), but to no avail.
How do I install those modules so that the correct files will be there?
On Ubuntu 14.04, I needed to sudo apt-get install libsnmp-perl
Install Perl Net::SNMP
perl -MCPAN -e 'install Net::SNMP'
You could try to install it using CPAN:
perl -MCPAN -e 'install HTML::Template'

Resources