On Apr 11, 2011, at 3:11 AM, Per Øyvind Karlsen wrote:
>>
> you mean dependency on 'string in DT_SONAME' rather than
> devel('string in DT_SONAME')? Because it's *NOT* a dependency
> on the the SONAME itself!
The state what the dependency is on.
I see
readlink(2)
as the essential change (to code I swiped from drepper;s readelf which katzj
re-hacked which
pnsarat added which ended up in a Mandriva patch which you've re-added).
The difference in the code is that there's a readlink call to follow a symlink,
whether ist "devel(foo)" or RPMNTAG_FILELINKTOS in use, the edge in the
dependency
graph is in the same direction, and between the same two packages, based on
a symlink (your code narrowly limits to *.so, the linkto dependencies
treat all symlinks the same way).
SO we're down to arguing the aesthetics and "conveneience" of
devel(foo)
and
the widdle depsolvers don't like handle file dependencies
even though that is indeed what RPM uses and does in metadata.
So what do *you* see in
Requires: devel(foo)
that *I* don't see?
>>
>> Why isn't the actual text string used by Elf good enough for RPM metadata?
> What string?
>>
>> Why is there a need for a "convenient" redundant dependency?
> I don't see the redundancy.
So because there is no redundancy, that means that its okay to add?
>>
>> Why isn't the rule
>> All symlinks require their end-point.
>> good enough and more general, with 0 additional data needed, gud enough?
> And yet again, there's *NO* dependency on any symlink endpoints,
You are correct that the symlink endpoit in not literally WYSIWYG and in toy
face with
Requires: devel(foo)
Yes there's no symlink end-point there.
Yes it doesn't look like a path.
> the 'symlink against SONAME' is merely used by the generator to determine
> whether to generate a devel() dependency or not, once dependency generated,
> there's not really any symlinks at all involved (except for the
> symlink in the -devel
> package, but as the dependency is against devel(...) in header, that's
> irrelevant)
The symlink indicates a direction and a node in a dependency graph.
How that edge in the dependency graph is expressed as a string, whether
a symlink or a SONAME, simply doesn't matter.
>>
>> This whole "devel(libz)" namespace is entirely Mandriva peculier:
>> Invented at Mandriva, used at Mandriva, wanted by Mandriva
>> No other distro has ever asked for
>> Requires: devel(zlib)
>> to be implemented in RPM. I talked at length with Stefan re exactly this
>> issue.
>>
>> I did not understand the need then, and I don't understand the need now.
> Simply you not understanding it yet, doesn't necessarily imply that there's no
> need, now does it?
The code is there. I don't like it and don't care to support. The
code is there regradless of need.
> To make it simple, it serves the same purpose as ie. pkgconfig() deps, but is
> determined by the library itself, rather than requiring pkg-config to
> be provided
> with it.
You cannot define the intent by analogy or by invalid deductive inference.
You want
Requires: devel(foo)
because you think that is "handy" and "convenient".
You think pkgconfig dependencies are less useful.
I disagree. So *YOU* can turn off pkgconfig dependecies, while *I*
am forced to pretend to support complex code, that I don't see a need for
in RPM, don't understand, and cannot disable in any other fashion than
by putting under a #ifdef RPM_VENDOR_MANDRIVA and arguing with you
about "handy" and "convenient".
I don't like or want this patch in RPM.
The patch is under #ifdef RPM_VENDOR_MANDRIVA because you need it and
that's the only way to turn it off.
> If not the attempt at explaining the technical details above succeeded, I'll
> rather try explain over IRC sometime later, but not today..
>>
>>> So just like libfoo.so.1 will pull in dependencies on any packages
>>> with libraries
>>> that it links against, devel() will pull in the same matching dependencies
>>> for the corresponding -devel packages. This is just as handy for -devel
>>> packages
>>> as the soname dependencies are for library packages.
>>>
>>
>> "handy" and "convenient" aren't any excuse for sound engineering.
> not understanding != sound engineering
>>
>>> I don't see the dependency loop you spoke of in the reply to Stefan btw.,
>>> it will only add dependencies on devel() provides, just like libfoo.so.1
>>> will
>>> add the same corresponding dependencies on other sonames..
>>
>> Turn on the LOOP messages, turn off the %_dependency_whiteout.
>>
>> A very common LOOP paradigm you will see involves a pair of libraries that
>> require each other.
> You mean manually added dependencies?
> Or autogenerated soname dependencies requiring each other?
I was replying to what I tried to convey to Stefan from 5 year old memory.
Yes "devel(foo)" dependcies are one of the edges in the LOOP.
Forcing RPM to deal with its own automatically generated LOOP's
is a painfulness I wish not to experience. Its hard enough to
deal with what package monkeys decide to put into metadata.
> If latter, the devel(...) dependencies will be pretty similar to it..
Exactly: automagically adding Requires: devel(foo) creates lots and lots of
LOOP's
That is what I saw in 2004 when I looked at Mandrake's dependency graph,
discussed
at length w Stefan, again re-iterated in 2006, and now stone cold leftovers
re-hashed and added to rpm code under #ifdef RPM_VENDOR_MANDRIVA for
you handy convenience.
I personally don't like the code, don't want the code in RPM, don't see the
need for "devel(foo)" that cannot be solved in other ways, and seriously
don't want to "SUPPORT" this patch.
73 de Jeff
smime.p7s
Description: S/MIME cryptographic signature
