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).
Why isn't the actual text string used by Elf good enough for RPM metadata?
Why is there a need for a "convenient" redundant dependency?
Why isn't the rule
All symlinks require their end-point.
good enough and more general, with 0 additional data needed, gud enough?
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.
> 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.
> 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.
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.
73 de Jeff
smime.p7s
Description: S/MIME cryptographic signature
