The program fix_libtool_files.sh and the called one fixlafile.awk have a MAJOR problem: they change of course the md5 and mtime of the .la files but don't update the portage database (CONTENTS files). So an "emerge -C foo" won't remove this changed files and this will bring to an unclean system and problems with some apps. To fix this in a cleaner way I did some things: 1) Added a class to portage_contents.py that let you manage CONTENTS file, get and edit the file properties like md5 and mtime. 2) We needed an "atomic" file update. Every time we change an .la file we have to updated the CONTENTS file that own that .la file. Doing this at the end of all the changes is ugly and less functional. For this reason I had to rewrite fixlafile.awk in python so I can add the functions provided by portage_contents.sh 3) On Travis Tilley request: removed the need to pass an OLDVER variabile to fix_libtool_file.sh, now every version that is different from the gcc current one is updated (this need some testing please). By now, fix_libtools_file.sh is used again and it'll call /usr/lib/python/bin/fixlafiles.py, probably it can be removed and fixlafiles.py can be called directly. I'll attach the new fixlafile.py, and patched against portage_contents.py and fix_libtool_files.sh
Created attachment 43982 [details] /usr/lib/portage/bin/fixlafiles.py
Created attachment 43983 [details, diff] portage_contents.py-20041114-01.patch
Created attachment 43984 [details, diff] fix_libtool_files.sh.patch
Created attachment 44757 [details] fixlafiles.py Better script, remove all the bashism, updated the CONTENTS only if the md5 and mtime registered in the CONTENTS are the same of the file.
Created attachment 44758 [details, diff] portage_contents.py-20041125-01.patch Now the contentsManager class can also act as a dict. Uses the same CONTENTS parsing used in portage.py.
*** Bug 64112 has been marked as a duplicate of this bug. ***
*** Bug 75850 has been marked as a duplicate of this bug. ***
*** Bug 75940 has been marked as a duplicate of this bug. ***
*** Bug 78598 has been marked as a duplicate of this bug. ***
*** Bug 79051 has been marked as a duplicate of this bug. ***
*** Bug 84440 has been marked as a duplicate of this bug. ***
*** Bug 87141 has been marked as a duplicate of this bug. ***
*** Bug 90292 has been marked as a duplicate of this bug. ***
*** Bug 90608 has been marked as a duplicate of this bug. ***
Oops, sorry for having added to an already long list of duplicates... Anyway, since i've wrote my own solution now, i will re-attach it here. Don't get me wrong, i don't claim it's better than Simone's one... at the contrary, i can only welcome the idea of some awk to python rewriting :) But it has the benefit to be non-intrusive, so maybe it could be used as a temporary fix or something like that.
Created attachment 57386 [details] (alternative fix) fix_contents This is an helper script to update the CONTENTS files.
Created attachment 57387 [details, diff] (alternative fix) fixlafiles.awk--fix_CONTENTS.patch And this is a small patch for the awk code to call it.
$ grep /lib/rcscripts/awk/fixlafiles.awk /var/db/pkg/*/*/CONTENTS /var/db/pkg/sys-devel/gcc-3.4.3.20050110-r2/CONTENTS:obj /lib/rcscripts/awk/fixlafiles.awk c8fd3851ccee57651e43cac458dba7c1 1113754816 Why is this assigned directly to portage? Toolchain, can these scripts be verified please?
Created attachment 58311 [details, diff] fix_libtool_files.sh.patch original patch bit-rotted.
*** Bug 93306 has been marked as a duplicate of this bug. ***
*** Bug 104443 has been marked as a duplicate of this bug. ***
This is really a problem for users dealing with stale files, resulting e.g. in grep /usr/lib/libfoo.la: No such file or directory /bin/sed: can't read /usr/lib/libfoo.la: No such file or directory libtool: link: `/usr/lib/libfoo.la` is not a valid libtool archive. errors. This bug is now open for over a year, what holds us back to fix this?
if this isn't getting looked at, could we at least get the current fix_libtool_files.sh to not touch mtimes or update the portage db with new mtimes & checksums? (bug #78597, bug #90292, and bug #87141)
(In reply to comment #23) > mtimes & checksums? (bug #78597, bug #90292, and bug #87141) er, bug #78598 that is.
What we do here is going to depend on what we decide with regards to bug #90744
we're getting rid of this stuff
*** Bug 124980 has been marked as a duplicate of this bug. ***
