Bug 56097
| Summary: | rpm --rebuild fails with fileutils 4.1.1 | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Raw Hide | Reporter: | Bernhard Rosenkraenzer <bero> |
| Component: | fileutils | Assignee: | Bernhard Rosenkraenzer <bero> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1.0 | CC: | jbj, teg |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2001-11-19 20:30:30 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Bernhard Rosenkraenzer
2001-11-12 19:58:20 UTC
And what issue would that be? Loads of mv: will not overwrite just-created [file] with [file]. errors during make install (basically one for every file). Try upgrading fileutils to the version in the rawhide tree and rebuilding mx to see for yourself. Might still be a fileutils issue; I'll debug this once the S390 stuff is done, unless you beat me to it. I was thinking of what the POSIX compliance issue would be... I've never seen Posix demand "don't do what the user say" before. Suspicious items from the changelog:
* mv now prompts before overwriting an existing, unwritable destination file
when stdin is a tty, unless --force (-f) is specified, as per POSIX.
[doesn't state what it does when stdin isn't a tty]
* cp's -P option now means the same as --no-dereference, per POSIX.
Use --parents to get the old meaning.
Is stdin really a tty when using rpm to build a package? rpm does not change stdin, only dup's fd #0 for running scripts. So stdin is whatever it is/was when rpm is/was invoked. The error seems genuine; just looked through the cp code causing the message:
/* Don't let the user destroy their data, even if they try hard:
This mv command must fail (likewise for cp):
rm -rf a b c; mkdir a b c; touch a/f b/f; mv a/f b/f c
Otherwise, the contents of b/f would be lost.
In the case of `cp', b/f would be lost if the user simulated
a move using cp and rm.
Note that it works fine if you use --backup=numbered. */
if (command_line_arg
&& x->backup_type != numbered
&& seen_dest (dst_path, dst_sb))
{
error (0, 0,
_("will not overwrite just-created %s with %s"),
quote_n (0, dst_path), quote_n (1, src_path));
return 1;
}
So this is a fileutils bug? It certainly looks like one... Reassigning component. Fixed in 4.1.2-2. |