On Nov 1, 2010, at 5:02 PM, Per Øyvind Karlsen wrote:
>>
>> But only for Mandriva.
> But you still get the same behaviour for other distros.
>
Arguing broken everywhere will only force me to consistent
behavior in RPM. Which is likely to be the opposite of
what you want to happen (i.e. I'll just rip the patch).
In fact, Mandriva likely does more
Provides: /path/to/file
to minimize the size of createrepo-like spewage than other distros.
Minimizing the size of an output file by inserting data into a different
tag (thereby causing it to be stored in a different index)
is kinda like me minimizing your monthly bank statement
by redirecting your salary into my account from yours. Sure
"works", but is hardly "correct". ;-)
What needs to be decided is
Where are strings that begin with '/' stored?
One solution is to choose the store index based on whether
the 1st character is '/' (or not), not whether the tag was
Provides: or in %files. But that has issues too (see below).
Meanwhile I'm gonna add RPM_VENDOR_MANDRIVA until I get a chance
to look and think more carefully. Your patch also enables patterns,
which means that
Provides: /path/to/file.*
start to go active as a side effect. Which changes the lookup
of, say, a glob to a non-existent file into a *RE applied
to Providename: keys, surely not what is intended or desired.
> In rpmdb.c:694
>
> qva->qva_mi = rpmtsInitIterator(ts, RPMTAG_FILEPATHS, fn, 0);
> if (qva->qva_mi == NULL && !provides_checked && !gotpattern)
> qva->qva_mi = rpmtsInitIterator(ts, RPMTAG_PROVIDENAME, fn, 0);
>
> if (qva->qva_mi == NULL) {
> struct stat sb;
> if (!gotpattern && Lstat(fn, &sb) != 0)
> rpmlog(RPMLOG_NOTICE, _("file %s: %s\n"), fn, strerror(errno));
> ...
>
> I was first wondering if checking with 'rpmmiCount(qva->qva_mi) == 0'
> (rpmtsInitIterator(ts, RPMTAG_PROVIDENAME, fn, 0) doesn't return NULL
> unless my change is done) in addition, but doing the change I did
> seemed more consistent with existing behaviour.
>
> Am I missing something? :o)
>
You probably are not missing anything at all.
But "RPM ACID" is betwixt and between the old Basenames and the newer Filepaths
index,
and turning on
Provides: /path/to/file
just makes matters yet more confusing because it adds a 3rd index.
What needs to happen finish (imho) is
1) finish removing the Basenames index entirely, always use Filepaths.
2) try adding adding
Provides: /path/to/file
as if it had been specified as
%files
%ghost /path/to/file
(which is closer to being a "supported" virtual file than anything else)
The failure case will be if BOTH
Provides: /path/to/file
and
%files
/path/to/file
are specified in the same package: that breaks the uniqueness constraint that
is currently necessary using DB->associate(), and likely will cause an rpmdb
failure.
But for now I'm gonna check in #ifdef RPM_VENDOR_MANDRIVA until
I get a chance to look more closely.
73 de Jeff______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
