Bug 1277104 - Please remove sysconfig directory correctly
Please remove sysconfig directory correctly
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: thinkfan (Show other bugs)
22
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Sandro Mani
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-02 06:24 EST by Ali Akcaagac
Modified: 2015-11-02 12:18 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-02 12:18:17 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ali Akcaagac 2015-11-02 06:24:15 EST
Two updates within a couple of days and still problems:

  Cleanup     : thinkfan-0.9.2-4.fc22.i686                                48/55 
warning: file /etc/sysconfig/thinkfan/thinkfan.sysconfig: remove failed: Not a directory

-bash-4.3$ cd /etc/sysconfig/
-bash-4.3$ ls -l
total 76
-rw-r--r-- 1 root root  403 Nov  1 00:00 atd
-rw-r--r-- 1 root root  430 Nov  1 00:00 authconfig
drwxr-xr-x 2 root root 4096 Nov  1 00:00 cbq
drwxr-xr-x 2 root root 4096 Nov  1 00:00 console
lrwxrwxrwx 1 root root   17 Nov  1 00:00 grub -> /etc/default/grub
-rw-r--r-- 1 root root  798 Nov  1 00:00 init
-rw-r--r-- 1 root root 1753 Nov  1 00:00 ip6tables-config
-rw-r--r-- 1 root root 1740 Nov  1 00:00 iptables-config
-rw-r--r-- 1 root root  185 Nov  2 12:14 kernel
drwxr-xr-x 2 root root 4096 Nov  1 00:00 modules
-rw-r--r-- 1 root root  634 Nov  1 00:00 netconsole
-rw-r--r-- 1 root root   22 Nov  1 00:00 network
drwxr-xr-x 2 root root 4096 Nov  1 00:00 network-scripts
-rw-r--r-- 1 root root   45 Nov  1 00:00 ntpd
-rw-r--r-- 1 root root  111 Nov  1 00:00 ntpdate
-rw-r--r-- 1 root root 2915 Nov  1 00:00 raid-check
-rw-r--r-- 1 root root  714 Nov  1 00:00 readonly-root
-rw-r--r-- 1 root root   13 Oct 27 00:03 thinkfan
drwxr-xr-x 2 root root 4096 Nov  1 00:00 thinkfan.rpmmoved
-rw-r--r-- 1 root root  644 Nov  1 00:00 wpa_supplicant
-bash-4.3$ 

thinkfan.rpmoved *is not* removed! just renamed and remain as orphaned dead directory inside there! If I would have been an unexperienced admin, I wouldn't even know which file is which and which one to alter.
Comment 1 Sandro Mani 2015-11-02 07:08:54 EST
I've used the recommended snippet from the Fedora wiki [1]. (Although I did forget to mark the directory as %ghost). It is unclear from that page if the admin himself is responsible for removing that file, but I would assume so - after all, also in the case of *.rpmnew and *.rpmsave it is the responsibility of the admin to clean up those files, the packages do not own them. So all in all I'm not sure there really is a benefit of building another update with the %ghost - admins are most likely familiar with the fact that files/folders with a .rpm* suffix are files they need to handle/clean up.

[1] https://fedoraproject.org/wiki/Packaging:Directory_Replacement#Scriptlet_to_replace_a_directory
Comment 2 Ali Akcaagac 2015-11-02 11:08:06 EST
No offense but your package is the only one that can not deal with removing incorrectly created directories. If you are unsure how to deal with the package then please ask on the devel-list for appropriate support.

I used the terminology "Admin" in terms of someone who knows what to do and how to do it. Most likely experienced Linux users do know. But Fedora offers Workstations as well and people either manually update via dnf update, yum update or some packagekit magic.

The amount of new to be updated packages that flow in every now and then (for example 50 and more) usually creates a lot of output which otoh leads to people ignoring most of the text that show up. Mistakes are showing up much later once someone becomes irritated by similar or incorrectly placed files (and directories) in the /etc directory (including recursive subdirectories).

Your earlier package caused *a* problem, the later package solves the earlier packages problem only by half. Leaving some old cruft.

I seriously expect this to be avoided in first place and would like that this release is being unpushed and replaced by something that installs the files in the correct directories *and* removing old directories accidently created.

By the way:

The scriplet you are reffering to under [1] deals with directories that might contain other files.

e.g.

If you put files into /etc or /etc/sysconfig then your script shall not remove /etc or /etc/sysconfig because these directories contain other files that are a mandatory requirement for the system to work (in worst case boot up).

This is a huge difference to your directory that got accidently created in your earlier package. A directory that only belongs to thinkfan.

If you refer to the scriptlet above then you shouldn't even rename the directory to rpmmoved at all. The correct expectation for this case is to remove that directory entirely.

Or differently, the page you are reffering to is not subject to this use case because it explains about directory replacement. Your use case otoh is "removing an accidental created directory". Something that shouldnt be there in first case.

So please correct this.
Comment 3 Sandro Mani 2015-11-02 11:24:56 EST
The problem here is not just "removing an incorrectly created directory", but "replacing an incorrectly created directory with a file with the same name". And this is what is documented in the wiki page:

"RPM cannot simply remove a directory when it is replaced by a file or symlink", 

The second part of that sentence,

"since users may have added or modified files to the directory."

is merely and explanation why it cannot do so, and not a precondition about the scenario when it cannot do so. Any replacement of directory with a file of the same name will have you hit this issue, regardless of what is inside the directory.

So while I'm very sorry for not having noticed the issue before pushing the initial build, to the best of my knowledge this is the best way to resolve the issue.
Comment 4 Ali Akcaagac 2015-11-02 11:49:59 EST
Ah yes I understand the problem now!

With my own words: "The problem ist the initial /etc/sysconfig/thinkfan/... directory which is now being replaced by a file with the same name. Therefore the directory has to be renamed to *.rpmmove because it has to create space for the file with the same name."

...

I need to think about this issue for a while and come back later to this report. Meanwhile it allows other people to comment on it ...
Comment 5 Sandro Mani 2015-11-02 11:59:42 EST
Okay, I won't be pushing anything to stable in the meantime. But again, I don't see this as something excessively tragic: also in the case of *.rpmsave and *.rpmnew files, created regularly by updates, the user will need look for these files and handle them on a case-by-case basis. This, while originating from a mistake on my part, is not really different, and I don't expect it to cause much trouble for anyone really. Just delete in and move on.
Comment 6 Sandro Mani 2015-11-02 11:59:52 EST
*delete it
Comment 7 Ali Akcaagac 2015-11-02 12:15:01 EST
Yes you are right. I haven't had the same dirname/filename *problem* infront of my eyes when I wrote the report.

The thing is that I have an automatic process dealing with installations and updates of systems (RHEL, CENTOS, FC and so on). I deal with *rpmnew and *rpmsave files and am well aware of them. The *rpmmove stuff is rarely happening (and to say the truth, I never have seen this for myself before). Automatic processing of said files (not dirs) is trivial but doing so with *rpmmove needs some enchancement of my own infrastructure, that's why I mentioned that I have to think about that issue for a while.

Best is we close the bug here and thanks for clarification.
Comment 8 Sandro Mani 2015-11-02 12:18:17 EST
Okay, apologies for the trouble.

Note You need to log in before you can comment on or make changes to this bug.