Bug 1062956

Summary: _install_langs macro is looked at for removals as well as installs.
Product: [Fedora] Fedora Reporter: James Antill <james.antill>
Component: rpmAssignee: Packaging Maintenance Team <packaging-team-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: ffesti, jzeleny, novyjindrich, packaging-team-maint, pknirsch, pmatilai
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1062957 (view as bug list) Environment:
Last Closed: 2014-02-09 14:02:38 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1062957    

Description James Antill 2014-02-09 09:00:06 UTC
Description of problem:
The _install_langs macro is obeyed for removals as well as installs, instead of rpm just looking at if the files are marked as skipped from the install side. This means that it's really hard to use the macro, and the obvious usecase will leave "random" files on the disk.


Version-Release number of selected component (if applicable):
rpm-4.11.1-10.fc20.i686


How reproducible:
Always

Steps to Reproduce:
1. Change _install_langs to en:es
2. rpm -Uvh blah.rpm
3. Change _install_langs to de:en
4. rpm -e blah.rpm
5. rpm -Uvh blah.rpm

Actual results:
You'll now have de:en:es lang files (although the "de" language files will confusingly be in rpm -ql but not matched via. rpm -qf).

Expected results:
Just have de:en files.

Additional info:
In real life you'll be doing a yum reinstall, so steps #4 and #5 happen at the same time (so it's not possible to move #3 after #4).

Comment 1 Panu Matilainen 2014-02-09 14:02:38 UTC
Nope, removal does not care about _install_langs, and (expectedly) the reproducer doesn't behave the way you claim it does:

[root@mursu ~]# rpm -D "_install_langs en:es" -Uvh /home/pmatilai/rpmbuild/RPMS/flangtest-1.0-1.noarch.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:flangtest-1.0-1                  ################################# [100%]
[root@mursu ~]# ls /usr/share/flangtest/empty.txt  en.txt  es.txt  none.txt
[root@mursu ~]# rpm -D "_install_langs de:en" -e flangtest
[root@mursu ~]# ls /usr/share/flangtest/
ls: cannot access /usr/share/flangtest/: No such file or directory
[root@mursu ~]# rpm -D "_install_langs de:en" -Uvh /home/pmatilai/rpmbuild/RPMS/flangtest-1.0-1.noarch.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:flangtest-1.0-1                  ################################# [100%]
[root@mursu ~]# ls /usr/share/flangtest/de.txt  empty.txt  en.txt  none.txt
[root@mursu ~]# 

The actual reproducer for this involves --force (which equals --replacepkgs and --replacefiles, which is what yum does for reinstall, quite likely because it has to):
[root@mursu ~]# rpm -D "_install_langs en:es" -Uvh /home/pmatilai/rpmbuild/RPMS/flangtest-1.0-1.noarch.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:flangtest-1.0-1                  ################################# [100%]
[root@mursu ~]# ls /usr/share/flangtest/
empty.txt  en.txt  es.txt  none.txt
[root@mursu ~]# rpm -D "_install_langs de:en" -Uvh --force /home/pmatilai/rpmbuild/RPMS/flangtest-1.0-1.noarch.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:flangtest-1.0-1                  ################################# [100%]
[root@mursu ~]# ls /usr/share/flangtest/
de.txt  empty.txt  en.txt  es.txt  none.txt
[root@mursu ~]# 

This is a dupe of bug 966715: what happens on such "reinstall" is NOT an upgrade-like install + erase operation consisting of two transaction elements, its a strange hack that only ever works on a highly specific case of replacing eg corrupt or accidentally erased file of a package, and never erases anything at all.

Its an ugly thing, but fixing it isn't as easy as it might seem due to various funny internals.

*** This bug has been marked as a duplicate of bug 966715 ***