Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

etc-updates preserves the timestamp of the ._cfg files it updates. This is bad,
like so

/etc/init.d/checkfs - depends on checkroot and has a timestamp of 1
baselayout upgrade
/etc/init.d/._cfgcheckfs - depends on checkroot and volumes and has a timestamp
of 2
baselayout does depscan.sh -u, to force a deptree update and has a timestamp of
3
user etc-updates checkfs
user reboots - but because checkfs timestamp is older than deptree, we don't
recalc the deptree.

Solution is to touch the file updated to ensure that the timestamp is newer.
If this bug is not solved, people will have a big problem with the
baselayout-1.13 upgrade if they use LVM, RAID, or anything listed in
RC_VOLUMES.

Created an attachment (id=104364) [details]
Touch file after updating.

This fixes the issue.

(In reply to comment #1)
> Created an attachment (id=104364) [edit] [details]
> Touch file after updating.
> 
> This fixes the issue.
> 

Is there any other alternative?  Due to bug 16162, this change will reopen bug
8423.

(In reply to comment #0)
> user etc-updates checkfs
> user reboots - but because checkfs timestamp is older than deptree, we don't
> recalc the deptree.

The timestamp represents the time that the file is merged.  Isn't that enough
to force a recalc of the deptree if the user runs etc-update just after the
baselayout update (like they're supposed to)?

(In reply to comment #2)
> Is there any other alternative?  Due to bug 16162, this change will reopen bug
> 8423.

Sure there are alternatives, but remember that the test is run each time a
service is started/stopped.

Testing the mtime of a file in /etc against the mtime of the deptree is very
fast as bash supports this in conditions. Another method, like say store the
mtime or md5sum in a file and compare if it's changed or not would be slower.
Also, no tools to do this are available in /bin or /sbin which is where they
would need to be.

There is another alternative though - force an update the deptree after
etc-update if any where updated.

[[ -x /sbin/depscan.sh ]] && /sbin/depscan.sh -u

But don't be to hasty in doing that either, because if ANY other program relies
on mtimes in /etc to regenerate anything they will be broken too.

Lastly, I'd like to see this patch or the old behavior restored anyway as
logically, if etc-update needs to update file foo, then I would expect the
mtime to be updated to when that file was updated by me or etc-update.

(In reply to comment #3)
> The timestamp represents the time that the file is merged.  Isn't that enough
> to force a recalc of the deptree if the user runs etc-update just after the
> baselayout update (like they're supposed to)?

No, as we don't store the timestamp of the file to comapre as we don't have the
tools in /bin or /sbin. Also, that's a bit of a speed hit too.

Just a note to say that this behavior breaks stable baselayout too - a good job
that the portage version this bug is in isn't stable :)

(In reply to comment #0)
> If this bug is not solved, people will have a big problem with the
> baselayout-1.13 upgrade if they use LVM, RAID, or anything listed in
> RC_VOLUMES.

OK, baselayout-1.12.8-r1 and 1.13.0_alpha10-r1 also check the mtime of
/etc/init.d and /etc/conf.d
As 1.13 adds a new init script, the mtime is updated and thus depscan.sh can
pick this up.

However, this bug is still valid if devs update deps in init scripts they can
no-longer rely on etc-update completing the upgrade as the user will have to
manually run "depscan.sh -u" until portage team can solve this one.

(In reply to comment #6)
> However, this bug is still valid if devs update deps in init scripts they can
> no-longer rely on etc-update completing the upgrade as the user will have to
> manually run "depscan.sh -u" until portage team can solve this one.

I don't understand why they need to manually run "depscan.sh -u".  If a file is
updated then the timestamp on it's parent directory changes, so shouldn't the
service script detect that automatically or am I missing something?

the mtime of the directory is *not* updated when files inside of it are
modified

(In reply to comment #8)
> the mtime of the directory is *not* updated when files inside of it are
> modified

When the contents changes, such as when one file replaces another (like
etc-update does), the directory mtime does change (at least that's what my
experience shows).

it isnt about file contents, it's about the directory contents ... so modifying
a file will not update the mtime

(In reply to comment #10)
> it isnt about file contents, it's about the directory contents ... so modifying
> a file will not update the mtime

Okay, but don't the service scripts check the mtime of both to see if any one
of them is newer than the depscan cache?

(In reply to comment #11)
> Okay, but don't the service scripts check the mtime of both to see if any one
> of them is newer than the depscan cache?

They do as of 1.12.8-r1, but that's no good if an upgrade only replaces files
that already exist. If the deps in the init scripts have changed AND depscan.sh
has updated the deptree BEFORE the user etc-updates but AFTER the time merged
then the etc-updated mtime will be older than the deptree which causes
depscan.sh to think it doesn't need to run as it was created AFTER the new init
script, which is wrong.

I'm sorry, but I still fail to see how bumping the mtime on the directory could
be any less useful than bumping the mtime on the file.  It's just a boolean
flag, isn't it?  Why does it matter whether you use a single file mtime or a
combination of file and directory mtimes for this boolean flag?  If not, I
guess you guys will have to explain this to me on irc because I'm just not
getting in here. :)

I must be having a brain fart - the act of moving the ._cfg file to the new
file will of course bump the mtime on the directory.