Bug 1277104

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

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.

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.

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 ...

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.

*delete it

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.

Okay, apologies for the trouble.