2

I Create some file in %post script of rpm as follow

--spec file version 1.1 --

%post
  echo %{version} `date` > /var/info

Above script is not present old rpm (i.e version <= 1.0). /var/info file is created when new (version 1.1) rpm is installed

I downgrade package as follow

rpm -Uvh --oldpackage myrpm-1.0.rpm

I want remove /var/info file when downgrade rpm.

if I include following script as follow then it remove file on uninstall but not upgrade. --- spec file---

 %postun
    if [ $1 =="0" ]
       rm /var/info
    fi

Can you please help me to remove file if I downgrade to version < 1.1

Kalpesh Chavan
  • 56
  • 10

2 Answers2

3

I think the following %triggerin scriptlet in 1.1 spec can remove /var/info on downgrade to 1.0:

%triggerin -- %{name} < 1.1
rm /var/info

but RPM triggers this %triggerin on upgrade to 1.1 too. See below for details:

Update: I've wrote RPM macros for workaround:

fumiyas
  • 367
  • 3
  • 11
2

I don't believe you can do this using scriptlets only. That being said creating files like this using scriptlets is a bad idea (for exactly this sort of reason).

What you want for this is:

The %ghost Directive

As we mentioned in the Section called The %files List, if a file is specified in the %files list, that file will automatically be included in the package. There are times when a file should be owned by the package but not installed - log files and state files are good examples of cases you might desire this to happen.

The way to achieve this, is to use the %ghost directive. By adding this directive to the line containing a file, RPM will know about the ghosted file, but will not add it to the package. However it still needs to be in the buildroot. Here's an example of %ghost in action.

The blather-1.0 package logs to /var/log/blather.log in it's default config. In the spec file, the /var/log/blather.log file is included in the %files list. We can see that blather.log belongs to the package, and it is removed when the package is.

%install
touch $RPM_BUILD_ROOT%{_localstatedir}/log/blather.log
…
%files
…
%ghost %{_localstatedir}/log/blather.log
…
# rpm -qf /var/log/blather.log
blather-1.0-1
# rpm -ql blather | grep blather.log

# rpm -e blather && ls /var/log/blather.log
ls: /var/log/blather.log: No such file or directory

There file touched in the %install stage will not be installed to /var/log/blather.log although it will be added to the rpm database, as we can see from querying the file, however it is not visible from a package listing, but as it is owned by the package it will be removed when the package is removed. In addition it is possible to use setperms to fix the permissions on a %ghost file.

# ls -al /var/log/blather.log
-rw-r--r-- 1 root root 3448 Jun 18 17:00 /var/log/blather.log
#chmod 666 /var/log/blather.log
# ls -al /var/log/blather.log
-rw-rw-rw- 1 root root 3448 Jun 18 17:00 /var/log/blather.log
#rpm --setperms blather
# ls -al /var/log/blather.log
-rw-r--r-- 1 root root 3448 Jun 18 17:00 /var/log/blather.log

Etan Reisner
  • 77,877
  • 8
  • 106
  • 148
  • Thanks, But in my case if my file name and Directory will not fixed , it will be calculated depending on other package like perl ( perl sitelibe). it might be diffrent if enduser will use /opt/custpmeper/bin/perl. my installation file should go there rather that it will be fix as i use /usr/local/bin/perl in build env. can you sugeest any solution for it, actually i create link of files in user perl dir. to avoid issue. – Kalpesh Chavan May 08 '14 at 07:43
  • I don't think I understand your statement as such. You are running the perl that exists in the path on the installed system to recover its `sitelib` directory and then linking your packaged files into that directory (from whatever directory you actually installed them to) to ensure that they will be available to the default system perl (which may or may not be the official perl RPM)? – Etan Reisner May 08 '14 at 16:39