RPM Community Forums

Mailing List Message of <rpm-devel>

Re: [CVS] RPM: rpm/ CHANGES rpm/lib/ librpm.vers rpmds.c rpmds.h rpmfc.c

From: Per Øyvind Karlsen <pkarlsen@rpm5.org>
Date: Mon 11 Apr 2011 - 09:13:14 CEST
Message-ID: <BANLkTinfGEmVpc9tLg1d6iOdF-CcmR1TcA@mail.gmail.com>
I hate gmail...

2011/4/11 Per Øyvind Karlsen <peroyvind@mandriva.org>:
> 2011/4/11 Jeff Johnson <n3npq@mac.com>:
>>
>> On Apr 11, 2011, at 12:29 AM, Per Øyvind Karlsen wrote:
>>
>>> wrong sender.. fgrf
>>>
>>> ---------- Forwarded message ----------
>>> From: Per Øyvind Karlsen <peroyvind@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 <n3npq@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
>
Received on Mon Apr 11 09:13:15 2011
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.