158548 2006-12-19 08:11 0000 etc-update preserves timestamps 2006-12-21 00:48:11 0000 1 1 1 Unclassified Gentoo Linux Core system unspecified All Other RESOLVED FIXED P2 normal --- 1 uberlord@gentoo.org dev-portage@gentoo.org base-system@gentoo.org uberlord@gentoo.org 2006-12-19 08:11:18 0000 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. uberlord@gentoo.org 2006-12-19 08:30:16 0000 Created an attachment (id=104364) Touch file after updating. This fixes the issue. zmedico@gentoo.org 2006-12-19 12:45:30 0000 (In reply to comment #1) > Created an attachment (id=104364) [edit] > Touch file after updating. > > This fixes the issue. > Is there any other alternative? Due to bug 16162, this change will reopen bug 8423. zmedico@gentoo.org 2006-12-19 12:52:59 0000 (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)? uberlord@gentoo.org 2006-12-20 02:07:07 0000 (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. uberlord@gentoo.org 2006-12-20 02:09:06 0000 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 :) uberlord@gentoo.org 2006-12-20 08:20:02 0000 (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. zmedico@gentoo.org 2006-12-20 18:20:13 0000 (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? vapier@gentoo.org 2006-12-20 19:20:49 0000 the mtime of the directory is *not* updated when files inside of it are modified zmedico@gentoo.org 2006-12-20 19:24:20 0000 (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). vapier@gentoo.org 2006-12-20 19:28:19 0000 it isnt about file contents, it's about the directory contents ... so modifying a file will not update the mtime zmedico@gentoo.org 2006-12-20 19:58:34 0000 (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? uberlord@gentoo.org 2006-12-21 00:09:34 0000 (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. zmedico@gentoo.org 2006-12-21 00:27:44 0000 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. :) uberlord@gentoo.org 2006-12-21 00:48:11 0000 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. 104364 2006-12-19 08:30 0000 Touch file after updating. etc-update.patch text/plain LS0tIGV0Yy11cGRhdGUub3JpZwkyMDA2LTEyLTE5IDE2OjI4OjE0LjAwMDAwMDAwMCArMDAwMAor KysgZXRjLXVwZGF0ZQkyMDA2LTEyLTE5IDE2OjI5OjAxLjAwMDAwMDAwMCArMDAwMApAQCAtMzM1 LDYgKzMzNSw4IEBACiAJCWNhc2UgJHtteV9pbnB1dH0gaW4KIAkJCTEpIGVjaG8gIlJlcGxhY2lu ZyAke29maWxlfSB3aXRoICR7ZmlsZX0iCiAJCQkgICBtdiAke212X29wdHN9ICR7ZmlsZX0gJHtv ZmlsZX0KKwkJCSAgICMgRW5zdXJlIHRoYXQgdGhlIHRpbWVzdGFtcCBpcyBub3csIHNlZSBidWcg IzE1ODU0OC4KKwkJCSAgIHRvdWNoICR7b2ZpbGV9CiAJCQkgICBbIC1uICIke09WRVJXUklURV9B TEx9IiBdICYmIG15X2lucHV0PS0xCiAJCQkgICBjb250aW51ZQogCQkJICAgOzsK