http://bugzilla.suse.com/show_bug.cgi?id=1172521
http://bugzilla.suse.com/show_bug.cgi?id=1172521#c4
--- Comment #4 from Thorsten Kukuk
Maybe the changes were part of the fix, but they were forgotten? Just a guess.
I don't know, could be.
With read-only root filesystems and transactional-updates, this is a bad idea.
What exactly is a bad idea, please?
Everything below /usr should never be modified by a script, at runtime or anything else. You even don't know if it is possible or not. Additional, this prevents from checking /usr if somebody tampered with it or not
Since this is pretty old code looking like some update cleanup, I question if we need that at all or couldn't remove it completely.
"pretty old"? How old? Could you please point me to an exact revision? AFAIK there is no "osc blame", so I can not find it myself.
I don't know a tool, but you can go through the SLE11 maintanence updates and search for the first update introducing this code. According to the changes file it looks like it's from 2012. It was introduced with an SLES11 update, so there should be no system outside anymore which needs this code. So the %post will never be executed again and can be removed, including the PreReq line. Another question is the "%verify(not link md5 size mtime) %{_datadir}/zoneinfo/posixrules" line. This prevents our tools to find out if somebody tampered with /usr. Which is already bad. As this file is coming from the package itself, I don't see a need for it. Another question coming up is: does zic or something else modifies this file? If yes, we need another solution for this, with "Carwos", "MicroOS", "Kubic", "Transactional Server", /usr is read-only and this file cannot be modified by the admin. Another reason why the %verify statement is bad: it prevents us from finding such cases early, where tools modify data below /usr and fix them. -- You are receiving this mail because: You are on the CC list for the bug.