|
Bugzilla – Full Text Bug Listing |
| Summary: | Currently the libc function glob() is broken in BETA. | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE Linux 10.1 | Reporter: | Dr. Werner Fink <werner> |
| Component: | Basesystem | Assignee: | Michael Schröder <mls> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | mls |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | SUSE Other | ||
| Whiteboard: | |||
| Found By: | Development | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Dr. Werner Fink
2005-10-19 16:51:03 UTC
It's because there's a "ifarch none" around all the patches, including glibc-2.3.3-glob-revert-stale-symlinks.diff ... No, it is because our RPM or spec files are broken according to some "wise" glibc guru. Michael, do you know how RedHat solves this problem with rpm? Our rpm should work with a plain glibc, too, and not depend on special, incompatible changes to the default behavior of glibc functions. They probably point the glob "stat" function to "lstat". But I want to know what the standards say in this case. I can't believe glob() cannot return dangling symlinks. That would mean "rm sym*" could never delete a dangling symlink. Hey, not fair. Don't assign this to me. Instead answer the question... See: glibc glob change: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=126460 rpm workaround: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134362 In other words: Uli Drepper again. Sigh. The standard is pretty unclear in our opinion (but it seems not for this wise glibc guru). Our rm works fine with deleting dangling symlinks with "rm sym*". Red Hat has no glob patches on glibc or coreutils. But I have no idea how they solved the rpm problem. They copied the old glob.c and fnmatch.c from the glibc into the rpm sources and use them. My point is I don't want to do this if glibc gets changed again in the near future... bash wisely doesn't use glibc's glob... (In reply to comment #5) > In other words: Uli Drepper again. Sigh. I wrote "a wise glibc guru". Who else? (In reply to comment #7) > They copied the old glob.c and fnmatch.c from the glibc into the rpm sources > and use them. > My point is I don't want to do this if glibc gets changed again in the near > future... The problem is: It is not trivial to revert Uli's changes. Since the compiler is fixed, the patches are currently enabled again. But with the next change from Uli to glob it could be that we have no real chance anymore to revert to the old behavior. Our current patch introduces an old bug for this and I'm only waiting for the next L3 call so that we have to remove the reverting patch. For that case we should be prepared with a working rpm. I've patched rpm. |