Comment # 4 on bug 1172521 from
(In reply to Marketa Calabkova from comment #3)

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