Bug 52725
Summary: | parent directories are infected with 'net shared' flag | ||
---|---|---|---|
Product: | [Retired] Red Hat Raw Hide | Reporter: | Enrico Scholz <rh-bugzilla> |
Component: | rpm | Assignee: | Paul Nasrat <nobody+pnasrat> |
Status: | CLOSED UPSTREAM | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 1.0 | ||
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: | 2006-02-12 20:15:22 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
Enrico Scholz
2001-08-28 14:25:26 UTC
Forgot to mention: the setup and filesystem package are from the roswell2-beta. *** Bug 52729 has been marked as a duplicate of this bug. *** *** Bug 90941 has been marked as a duplicate of this bug. *** I believe we're saying the same thing but have different vocabularies. Yes, rpm needs to be made smarter about rdonly and NFS paths. What's naive and primitive is that the policy decision of the current %_netsharedpath implementation is Don't install any file on this path. Yes, more sophisticated policies, like using the (now available) file class information are needed, but (at least in my vocabulary) that's brand new stuff, not the current dumbsh*t %_netsharedpath implementation. Are we in agreement? If so, what I'm look for is additional ideas about what policies rpm CLI users find useful because, without consensus on what should be done, I cannot proceed. (BTW, there's also an RFE for netsharedpath replacement someplace in my pile of rpm bugs, I'll probably dupe this bug there for everyone's sanity.) I can not fully agree with the second paragraph. I am using _netsharedpath in the following situations: * NFS mounts * read-only mounts (related with NFS) * directories mounted like 'mount --bind /foo /bar' * top-level directories of automounters * normal directories which are handled by other mechanisms (cfengine) For these situations, %_netsharedpath and its 'do not install any file there' policy is ideally; perhaps I would add the sentence '... but assume the files are already there' to it. Replacing %_netsharedpath with 'any readonly or NFS mountpoint' would not be enough. Fileclass information can help on some _netsharedpath anomalies but it is an independent technology. OK, then we agree. I'm not suggesting %_netsharedpath removal, only replacement with a more sophisticated set of policies. What stops me from adding Yet More Arcane side effects during install is that these policies can seem very mysterious and surprising, just like %config handling is, to the average user, so I need to start educating rpm users and warn them before just slamming in Yet More Arcane Stuff. Since I know (and have 3-4 bug reports to prove it ;-) you want better policies, would you mind writing up something and dropping an RFE on rpm-list and testers-list? Implementations are easy, consensus is hard ... Thanks. https://www.redhat.com/mailman/private/rpm-list/2003-May/msg00301.html But the misclassification of /usr described by this bug can not be solved by policies. ;) still with rpm-4.3.1-0.3 FWIW, this is only true for setup+filesystem into a chroot. This command gives expected results rpm -Uvh --define '_netsharedpath /usr/share/info' time-1.7-27.i386.rpm And here's the bleeping patch. Happy now? Index: lib/transaction.c =============================================================== ==== RCS file: /cvs/devel/rpm/lib/transaction.c,v retrieving revision 1.315.2.24 diff -u -b -B -w -p -r1.315.2.24 transaction.c --- lib/transaction.c 5 Jan 2006 20:11:50 -0000 1.315.2.24 +++ lib/transaction.c 12 Feb 2006 20:17:16 -0000 @@ -775,6 +775,9 @@ static void skipFiles(const rpmts ts, rp /*@innercontinue@*/ continue; if (strncmp(dn, *nsp, dnlen)) /*@innercontinue@*/ continue; + /* Insure that only the netsharedpath basename is compared. */ + if ((s = strchr((*nsp) + dnlen, '/')) != NULL && s[1] != '\0') + /*@innercontinue@*/ continue; if (strncmp(bn, (*nsp) + dnlen, bnlen)) /*@innercontinue@*/ continue; len = dnlen + bnlen; Seriously, you're the only person I know of messing around with setup+filesystem in chroot's using %_netsharedpath, and your programming skills could have found the problem in less time than you've whined about "rpm bugs" over the last several years. Fixed in rpm cvs, should be in rpm-4.4.5-0.10 when built. @comment #9: What means "only"? When you can not bootstrap a system because 'cpio' fails due to this misclassification, this is more than "only". The 'chroot' part is not true either; it happens on real system setups too (it's not trivial to inject rpm macros into anaconda, but it is possible). This bug affects not only setup+filesystems it causes the same failures with | %_install_langs C @comment #10: I am not sure about the history of this bug (4.5 years are too much for me to remember all details). But I am pretty sure that the chroot in the initial comment was used only to give you a reproducer and the problem occured in a (for you: some more) real-world situation. At this time, it was probably not critical enough for me to develop a bug-fix resp. the work-arounds were much easier. At some stage (2004/2005) the bug become critical but the workarounds were still easy and I had to support older rpm version which would not have a potential bugfix. So there was no reason for me to develop a patch (especially because trivial things like '-p' flags in 'gendiff' were ignored). Completely unrelated statements like "The %_netsharedpath mechanism is known feeble and deficient" or your comments <#9 in this bug are things which let me "whine about rpm bugs". An unhelpful pragmatism (e.g. bug #173285#3 translates to "I know, the current rpmdb functionality in chroot is shit, but I won't fix it" for me) is doing its part to make me upset about rpm. Nevertheless, much thanks for the fix; we will see when it will appear in FC. |