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.