2011/4/11 Per Øyvind Karlsen <[email protected]>: > wrong sender.. fgrf > > ---------- Forwarded message ---------- > From: Per Øyvind Karlsen <[email protected]> > Date: 2011/4/11 > Subject: Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ librpm.vers rpmds.c > rpmds.h rpmfc.c > To: [email protected] > > > 2011/4/11 Jeff Johnson <[email protected]>: >> 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 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. 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.. -- Regards, Per Øyvind ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List [email protected]
