I hate gmail...
2011/4/11 Per Øyvind Karlsen <peroyv...@mandriva.org>: > 2011/4/11 Jeff Johnson <n3...@mac.com>: >> >> On Apr 11, 2011, at 12:29 AM, Per Øyvind Karlsen wrote: >> >>> 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.. >> >> See the link where Stefan advocated. >> >>> >>> 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' >> >> You will need to give me an explicitly worked example >> because there can be multiple symlinks like here: >> >> lrwxrwxrwx 1 root root 13 Feb 22 18:11 /usr/lib/libz.so -> >> libz.so.1.2.5* >> lrwxrwxrwx 1 root root 13 Feb 14 12:33 /usr/lib/libz.so.1 -> >> libz.so.1.2.5* >> lrwxrwxrwx 1 root root 23 Feb 14 12:33 /usr/lib/libz.so.1.2.5 >> -> ../../lib/libz.so.1.2.5* >> >> The DT_SONAME is actually: >> >> $ readelf -a /usr/lib/libz.so.1.2.5 | grep SONAME >> 0x0000000e (SONAME) Library soname: [libz.so.1] >> >> And so I see >> $ rpm -q --provides libzlib-devel >> libz-devel = 1.2.5-3mdv2011.0 >> libzlib-devel = 1.2.5-3mdv2011.0 >> zlib-devel = 1.2.5-3mdv2011.0 >> uClibc-zlib-devel = 1.2.5-3mdv2011.0 >> uClibc-zlib1-devel = 1.2.5-3mdv2011.0 >> pkgconfig(zlib) = 1.2.5 >> ==> devel(libz) >> libzlib-devel = 1.2.5-3mdv2011.0 >> libzlib-devel(x86-32) = 1.2.5-3mdv2011.0 >> >> > and "devel(libz)" isn't an SONAME at all but rather something that you > are calling a SONAME. > pedant, I could've implied the distinction by saying "~SONAME", > "SONAME-so.1" or whatever, I assumed what was implied/my laziness > would be easy enough to grasp without obsessing about inaccuracies > by my laziness.. > I'm too tired for anal retentiveness right now.. >> >> And I don't know what you mean by "identifier" since I haven't any idea > Identifier == 'libfoo.so' symlink to ELF file with SONAME (ie. > libfoo.so -> libfoo.so.1) > Which implies ie. use with '/usr/bin/ld -lfoo', being part of -devel > package, and again devel(libfoo) > -lfoo -> devel(libfoo) > Notice the context? >> what is being identified (except de facto what Mandriva wants and what >> Stefan wanted etc). > If you understood what Stefan wanted here, then you should understand > what is wanted at: > https://lists.dulug.duke.edu/pipermail/rpm-devel/2006-April/001054.html > then you should understand what is wanted here as well as it's the exactly > same. > If not, then you didn't understand what Stefan wanted. >> >> >>> 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). >>> >> >> And so the DT_NEEDED (there is no DT_REQUIRED afaik) is actually: > DT_NEEDED, DT_REQUIRED, whatever, linguisticly equivalent enough > for my brain to mixing the name, and easy enough for others to figgure.. >> >> $ readelf -a /usr/lib/librpmio-5.3.so | grep NEEDED >> ... >> 0x00000001 (NEEDED) Shared library: [libz.so.1] >> >> or if you prefer >> >> $ ldd /usr/bin/rpm >> ... >> libz.so.1 => /lib/libz.so.1 (0xb65a7000) >> >> All of which appear consistently to claim "libz.so.1" as the SONAME. >> >> And "libz.so.1" does _NOT_ appear in >> Requires: devel(libz) > libz.so - ".so" > > With the -devel package depending on the library package with libz.so.1, > there's no need for specifying the full SONAME in devel(libz), the chain of > dependencies will automatically get sorted out correctly due to requiring > the packages with the SONAMES, for which SONAME dependencies > should ensure that the right package providing devel(libz) gets picked > if there would happen to be several packages providing devel(libz). > (notice that I've been up since saturday, Stefan was the author of the > original script that's currently in mandriva, not me, I'm merely dimly > remembering the details from faar back of my head, dating back to > somewhere around the same period as he wrote it. There was a > couple of weeknesses in his implementation that I've sorted out > already, but there might be others, and I might be partly at error > in remembering the logic. need to review again closer later, but > what currently is in mandriva works quite well (and as said, being > far more useful than ie. pkgconfig() deps for what it's worth..;)) >> >> >>> 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. >>> >> >> Um, I do not see "convenient" whatsoever. I see yet more confusion. > no wonder, "confusion" tends to easily get mutually exclusive with > "convenient".. ;) >> >>> 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. >>> >> >> WHo else but the Mandriva monoculture uses >> Requires: devel(foo) >> WHy SHOULDNT the code be under >> #ifdef RPM_VENDOR_MANDRIVA >> if only Mandriva uses? > Following that logic, there's tons of things in rpm that should be under #if > 0.. > > Even if only currently used by mandriva, there's nothing prohibiting > others from using it if desired. > Adding it as an optional dependency to be generated for any distro > to adopt if desired is what I see as being more vendor neutral than > making it #ifdef mandriva, for which only possible by mandriva to use, > which again quite strongly implies not being vendor neutral. > > It's a feature. Whoever might use it or not doesn't dictate whether > vendor neutral or not. >> >> And I don't see how a half assed patch checked in yesterday and examined >> today is a step away from anything whatsoever, including being "vendor >> neutral". > Considering you obviously don't seem to understand it, I'd say claims about > "half assed" are rather premature/ignorant.. >> >>> The devel() dependencies are way more useful in real world cooker usage >>> than ie. >>> the pkgconfig() etc. dependencies at least to my experienec.. >> >> I'm not in a position to say useful because I'm hearing no engineering >> argument, >> just cooker! convenient! DT_REQUIRED! >> and none of it makes any engineering sense. >> >> The original patch that was posted (which Stefan advocated) was an >> attempt to use only primary.xml and avoid having to download filelists.xml. >> I understand that original intent to minimize bandwidth (didn't and doesn't >> work >> as anticipated, but whatever). > I'm referring to > https://lists.dulug.duke.edu/pipermail/rpm-devel/2006-April/001054.html > which has *nothing* to do with primary.xml (notice Stefan contributed the > patch > from Mandriva, no primary.xml whatsoever here). > This is the *exact* same script that I've based my implementation on. >> >> I do not understand >> Requires: devel(libz) >> at all. > it fires on libz.so, most likely shaving off '.so' just because it's > kinda redundant > in the context.. >> >> For similar "primary.xml only download" reasons, Mandriva has chosen to do >> Provides: /path/to/file >> to populate synthesis files with paths. Rather silly and bizarre imho. > Shaving off 80% of metadata size so only synthesis is required should be > obvious > enough without being particularly silly or bizarre. > Provides: /path/to/file has been added to packages with files for > which rpm generates > scriptlet dependencies on. Just adding these as Provides: > /path/to/file so that we > get those few instances in synthesis rather than having to require metadata > with > all filenames that are several times larger than synthesis makes perfect > sense. > > I've explained this more than once in the past, dunno why you keep > rehashing it yet > again.. >> >> In my world Provides: != Filepaths ... in fact "providing" file paths forces >> a more complex implementation in RPM because everything starting with a '/' >> might be in either place (or even both places) which muddies many dependency >> implementation issue. > Last time we discussed this like 2-3 weeks ago, I explained why the specific > file provides weren't just added to synthesis when discovered generating it > (anymore, as it used to in the past). If there's still anything not > clear about it, > I'll happily explain over again, but just not today, need to finish up > writing some > school papers today with a deadline for tomorrow.. :| > > -- > Regards, > Per Øyvind > ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org
