2011/4/11 Jeff Johnson <n3...@mac.com>: > > On Apr 11, 2011, at 12:58 AM, Per Øyvind Karlsen wrote: > >> 2011/4/11 Per Øyvind Karlsen <pkarl...@rpm5.org>: >>> wrong sender.. fgrf >>> >>> ---------- Forwarded message ---------- >>> From: Per Øyvind Karlsen <peroyv...@mandriva.org> >>> Date: 2011/4/11 >>> Subject: Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ librpm.vers rpmds.c >>> rpmds.h rpmfc.c >>> To: rpm-devel@rpm5.org >>> >>> >>> 2011/4/11 Jeff Johnson <n3...@mac.com>: >>>> I knew I'd seen this symlink patch before: >>>> >>>> >>>> https://lists.dulug.duke.edu/pipermail/rpm-devel/2006-April/001037.html >>>> >>>> I did not like the patch the first time, and I don't like it 5 years later. >>>> >>>> I will rework the issue under #if RPM_VENDOR_MANDRIVA across the board. >>>> >>>> Note that the rule (already implemented except you've turned it off) >>>> All symlinks depend on their end-point. >>>> not only covers the special case of ELF libraries (when the symlink is >>>> explicitly "owned" by a package), but all other cases of symlinks to >>>> end-points in other packages. Yes you will need to teach URPMI and other >>>> depsolvers about symlink end-points constructed from RPMTAG_FILELINKTOS >>>> data, very not hard. >>>> >>>> The only remaining "feature" is the explicit >>>> Requires: devel(whatever) >>>> added to metadata. I fully realize the difficulties >>>> of transitive closure in "dependency hell", but hey, lets not >>>> go around in circles all over again. >>>> >>>> Note that the rule I've stated requires zero additional metadata, >>>> the linkto dependency is constructed on the install box from the symlink >>>> end-points that are already in metadata (but you're likely choosing to >>>> disable that functionality some 4? 5? years after being implemented). >>>> >>> Hm, I suspect you're misunderstanding the purpose of the devel() >>> dependencies.. >>> >>> They're not in place for adding dependencies on where symlinks points at, >>> but rather as an identifier for where 'symlink to SONAME ending with >>> .so in filename' >>> is considered as being part of a devel package, hence the >>> devel(soname) provides, >>> with requires added for all devel(SONAME) found under DT_REQUIRED (so it's >>> more >>> dependencies related to what libraries linked at rather than symlinks >>> endpoints to). >>> >>> These are actually quite convenient dependencies added, as it prevents >>> having to >>> manually add dependencies on other -devel packages in the -devel package >>> that >>> it usually tends to depend on. >>> >>> I'm okay with the helper beng disabled by default, but I really don't >>> see any good >>> reason for moving it under #ifdef mandriva, that would be a step away from >>> any attempts at vendor neutral approach IMO. >>> >>> The devel() dependencies are way more useful in real world cooker usage >>> than ie. >>> the pkgconfig() etc. dependencies at least to my experienec.. >> >> To be more specific to avoid confusions.. >> rpmdsSymlink() might've been a bad name for the function, but I was >> thinking that >> creating a generic rpmdsSymlink() function with possible uses for >> whateversomethingelse firing on symlinks in addition to this specific, >> only one single >> dependency type added to it so far.. >> >> In the patch from 2006 you referred to above, yes, what was done is >> automatically adding dependency on the library package which the symlinks >> points >> to, something which the runtime symlink dependencies you mention would do >> the same for. >> >> My patch (which is based on Stefan's from 2006, which you discuss at >> https://lists.dulug.duke.edu/pipermail/rpm-devel/2006-April/001058.html in >> the >> same thread) OTOH won't add any dependencies on any of the packages >> which the symlink points to, but rather create devel() dependency for -devel >> packages, as a counterpart to the soname dependencies for library. > > SO create devel dependencies if you want and put those in packages. You > are entirely free to do that. > > The one strongest (i.e always correct, no "soft" or Suggests: or anything > else) > is tracking sonames in packages. > > executables don't excute with missing libraries. Period. No one claims > anything different about the automation that puts > Requires: libz.so.1 > into package metadata. > > But Mandriva has chosen "devel(zlib)" instead of actually using > exactly the string in DT_SONAME (which is also present). 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! > > 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. > > 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, 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) > > 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? 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. 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? If latter, the devel(...) dependencies will be pretty similar to it.. > > The practice is widespread in Mandriva, and no place else. > > Because the practice is widespread and mostly consistent, I can see that > there is intent. > > What that intent is I haven't a clue. I have described the problems with > "stall-and-restart" > when LOOP's are present. All ordering problems MUST remove all LOOP's to > even begin diagnosing a problem. > > And Mandriva packages (in 2006) had more LOOP's than any other distro.
-- Regards, Per Øyvind ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org
