On Apr 16, 2011, at 11:34 AM, Per Øyvind Karlsen wrote: > 2011/4/16 Jeff Johnson <n3...@mac.com>: >> And so now we have the start of Yet More peculier dependencies, >> not just devel(...) but now uClibc(...). > Yes, this is to avoid conflicts with sonames linked against glibc, ie. see: > [peroyvind@lappis rpm-5.3.9]$ echo /usr/uclibc/usr/lib64/libz.so.1.2.5 > | LD_LIBRARY_PATH= tools/.libs/rpmdeps -P > elf(buildid) = 436568eecd8496e8648066fcacd79919833499b0 > libz.so.1()(64bit) > libz.so.1(ZLIB_1.2.0)(64bit) > libz.so.1(ZLIB_1.2.0.2)(64bit) > libz.so.1(ZLIB_1.2.0.8)(64bit) > libz.so.1(ZLIB_1.2.2)(64bit) > libz.so.1(ZLIB_1.2.2.3)(64bit) > libz.so.1(ZLIB_1.2.2.4)(64bit) > libz.so.1(ZLIB_1.2.3.3)(64bit) > libz.so.1(ZLIB_1.2.3.4)(64bit) > libz.so.1(ZLIB_1.2.3.5)(64bit) > $ LD_LIBRARY_PATH=/usr/uclibc/lib64 ldd /usr/uclibc/usr/lib64/libz.so.1.2.5 > linux-vdso.so.1 => (0x00007fff68dff000) > libc.so.0.9.30.3 => /usr/uclibc/lib64/libc.so.0.9.30.3 > (0x00007f99798ff000) > ld64-uClibc.so.0.9.30.3 => > /usr/uclibc/lib64/ld64-uClibc.so.0.9.30.3 (0x00007f99796f7000) > > Currently the uClibc-linked libraries are shipped together with the same > library > packages to ensure rpm not pulling in uClibc-linked library package only to > satisfy dependency for non-uClibc-linked stuff. > This adds a mandatory depedendency on uClibc for basesystem and relevant > packages for where shared uClibc-linked libraries are built for.. :|
And this is the reason for simple rules for ELF dependencies based
on DT_NEEDED and DT_SONAME.
Once you start adding namespace markers like devel(...) and now uClibc(...)
without any clear statement of what is intended (its is QUITE clear what
is intended with DT_SONAME/DT_NEEDED, that is _NOT_ true for devel(...) and
uClibc(...)
and so its just a long drawn out battle of hacks-to-hacks-to-hacks.
The choice to use uClibc (or not) is a "preference": and "preference"
cannot be automated in C code without a buttload of enablers/disablers
that aren't anywhere to be seen.
>>
>> Revert.
> Would you prefer for the patches to be maintained locally in cooker svn rather
> than under mandriva #ifdef?
I cannot maintain code that I can't test without installing Mandriva first.
And -- as reported to you privately -- its quite professionally embarassing
when I cannot even build from cvs, type make install, and attempt a
reproducer for an issue without wasting hours trying to figger out
WTF is in CVS and why.
I cannot afford that time since I work on many distros, not just Mandriva
Cooker.
>>
>> And get the fiddle ups in lib/psm.c for triggers
>> removed as well.
> Will do when I get there.
DIsabling exit code checking doesn't even begin to solve
whatever is wrong
/* Run triggers in this package other package(s) set off. */
rc = rpmpsmNext(psm, PSM_IMMED_TRIGGERS);
if(rc && !non_pre_scripts_dont_fail) break;
I offered to look and help with %systemd triggers and got brushed off.
And if anyone had bothered to even tell me that Mandriva file triggers
were going to be flipped into %triggers, I might well have been interested
in helping.
And if there was _ANY_ indication that %triggers* were either MUTSHAVE
or NICETOHAVE in Mandriva, I would most certainly be willing to help.
Instead -- when I asked yesterday -- "Are there any MUSTHAVE features?"
I'm told "No."
Where I come from "beta2" is rather late to start fiddling with
%_use_internal_dependency_generator and %triggers* and more.
But I fully understand the time pressures and "expedient hacks" that
then take years and years to weed out. Been there, done that, not any more.
Just a wee bit of planning goes a long long way.
73 de Jeff
>>
>> If you want hacked up RPM in Mandriva, by all means hack away.
> I am commiting the changes under mandriva #ifdefs only..
>
> --
> Regards,
> Per Øyvind
> ______________________________________________________________________
> RPM Package Manager http://rpm5.org
> Developer Communication List rpm-devel@rpm5.org
smime.p7s
Description: S/MIME cryptographic signature
