Re: [CVS] RPM: rpm-5_3: rpm/lib/ rpmfc.c
Ok enough.
We _ARE_ headed for a fork between rpm5.org - Mandriva if these check-ins
continue.
I've asked for discussion first. Not happening.
I've asked for a feature list. Not seen.
I've pointed out that many of these changes are ancient hysteria being
recycled as Newer! Better! Bestest!
There is noone asking for these changes. Show me.
There are no test cases. I will make that policy MANDATORY if necessary.
There is nothing but a 1-line description, essentially
Add new stuff.
No examples, no writeup, no usage case, nothing.
Its happening on the production branch (in this case) creating
divergence that I have to muck about with later, often breaking
code because I haven't any clue what is what.
None of this code is maintainable or useful imho until some of the above is
corrected.
73 de Jeff
On Apr 16, 2011, at 10:27 AM, Per Øyvind Karlsen wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
Server: rpm5.org Name: Per Øyvind Karlsen
Root: /v/rpm/cvs Email: pkarl...@rpm5.org
Module: rpm Date: 16-Apr-2011 16:27:26
Branch: rpm-5_3 Handle: 2011041614272600
Modified files: (Branch: rpm-5_3)
rpm/lib rpmfc.c
Log:
kernel(...) dependency helper seems to have been missing from earlier
commit, really commit now (and place it under mandriva #ifdef only for
now)
Summary:
RevisionChanges Path
1.73.2.8+19 -0 rpm/lib/rpmfc.c
patch -p0 '@@ .'
Index: rpm/lib/rpmfc.c
$ cvs diff -u -r1.73.2.7 -r1.73.2.8 rpmfc.c
--- rpm/lib/rpmfc.c 12 Apr 2011 08:02:30 - 1.73.2.7
+++ rpm/lib/rpmfc.c 16 Apr 2011 14:27:26 - 1.73.2.8
@@ -909,6 +909,19 @@
xx = rpmfcHelper(fc, 'P', gstreamer);
/* XXX: currently of no use, but for the sake of consistency... */
xx = rpmfcHelper(fc, 'R', gstreamer);
+#if defined(RPM_VENDOR_MANDRIVA)
+} else
+if ((fc-fcolor-vals[fc-ix] RPMFC_MODULE)) {
+miRE mire = mireNew(RPMMIRE_REGEX, RPMTAG_FILEPATHS);
+if (!mireRegcomp(mire,
^.*(/lib/modules/|/var/lib/dkms/).*\\.ko(\\.gz|\\.xz)?$))
+if (mireRegexec(mire, fc-fn[fc-ix], (size_t) 0) = 0) {
+fc-fcolor-vals[fc-ix] |= (RPMFC_MODULE|RPMFC_SCRIPT);
+xx = rpmfcHelper(fc, 'P', kernel);
+/* XXX: currently of no use, but for the sake of consistency...
*/
+xx = rpmfcHelper(fc, 'R', kernel);
+}
+mire = mireFree(mire);
+#endif
}
/*@-observertrans@*/
@@ -,6 +1124,12 @@
else if (!strncmp(fn, /gstreamer, sizeof(/gstreamer)-1)
fc-fcolor-vals[fc-ix] RPMFC_LIBRARY)
fc-fcolor-vals[fc-ix] |= (RPMFC_MODULE|RPMFC_SCRIPT);
+} else {
+miRE mire = mireNew(RPMMIRE_REGEX, RPMTAG_FILEPATHS);
+if (!mireRegcomp(mire,
^.*(/lib/modules/|/var/lib/dkms/).*\\.ko(\\.gz|\\.xz)?$))
+if (mireRegexec(mire, fc-fn[fc-ix], (size_t) 0) = 0)
+fc-fcolor-vals[fc-ix] |= (RPMFC_MODULE|RPMFC_SCRIPT);
+mire = mireFree(mire);
}
}
@@ .
__
RPM Package Managerhttp://rpm5.org
CVS Sources Repositoryrpm-...@rpm5.org
smime.p7s
Description: S/MIME cryptographic signature
Re: [CVS] RPM: rpm-5_3: rpm/lib/ rpmfc.c
2011/4/16 Jeff Johnson n3...@mac.com: Ok enough. We _ARE_ headed for a fork between rpm5.org - Mandriva if these check-ins continue. I've asked for discussion first. Not happening. I've asked for a feature list. Not seen. I've pointed out that many of these changes are ancient hysteria being recycled as Newer! Better! Bestest! There is noone asking for these changes. Show me. These are already in use on Mandriva and part of the helpers migrated from rpm-mandriva-setup. There are no test cases. I will make that policy MANDATORY if necessary. There is nothing but a 1-line description, essentially Add new stuff. No examples, no writeup, no usage case, nothing. ? Both commit messages, entry in CHANGES and the code itself should generally have at least the bare minimum to provide some pointers for it.. Its happening on the production branch (in this case) creating divergence that I have to muck about with later, often breaking code because I haven't any clue what is what. I've placed it under mandriva #ifdef, so it shouldn't break things for anyone else on the production branch.. None of this code is maintainable or useful imho until some of the above is corrected. If I'm gonna be able to migrate to the internal dependency generator, I must add these to avoid ~regressions. If a discussion and test cases is required provided first, I won't be able to have time to switching to the internal dependency before after next mandriva release.. Or I can go back to maintaining patches locally in cooker svn..? -- Regards, Per Øyvind __ RPM Package Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_3: rpm/ CHANGES rpm/lib/ rpmds.c
And so now we have the start of Yet More peculier dependencies,
not just devel(...) but now uClibc(...).
Revert.
And get the fiddle ups in lib/psm.c for triggers
removed as well.
If you want hacked up RPM in Mandriva, by all means hack away.
Not here.
73 de Jeff
On Apr 16, 2011, at 10:29 AM, Per Øyvind Karlsen wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
Server: rpm5.org Name: Per Øyvind Karlsen
Root: /v/rpm/cvs Email: pkarl...@rpm5.org
Module: rpm Date: 16-Apr-2011 16:29:45
Branch: rpm-5_3 Handle: 2011041614294401
Modified files: (Branch: rpm-5_3)
rpm CHANGES
rpm/lib rpmds.c
Log:
add a uClibc(...) dependency for libraries linked against uClibc to
avoid conflicting duplicates (mandriva only for now)
Summary:
RevisionChanges Path
1.3296.2.213+2 -0 rpm/CHANGES
2.167.2.13 +249 -49rpm/lib/rpmds.c
patch -p0 '@@ .'
Index: rpm/CHANGES
$ cvs diff -u -r1.3296.2.212 -r1.3296.2.213 CHANGES
--- rpm/CHANGES 12 Apr 2011 08:02:29 - 1.3296.2.212
+++ rpm/CHANGES 16 Apr 2011 14:29:45 - 1.3296.2.213
@@ -1,4 +1,6 @@
5.3.10 - 5.3.11
+- proyvind: add a uClibc(...) dependency for libraries linked against
+uClibc to avoid conflicting duplicates (mandriva only for now)
- devzero2000: get rid of rindex everywhere: use SUSv3 strrchr instead
- devzero2000: add more gpg keys to thkp.c test program
- jbj: verify: re-add digest/signature checks.
@@ .
patch -p0 '@@ .'
Index: rpm/lib/rpmds.c
$ cvs diff -u -r2.167.2.12 -r2.167.2.13 rpmds.c
--- rpm/lib/rpmds.c 11 Apr 2011 05:10:20 - 2.167.2.12
+++ rpm/lib/rpmds.c 16 Apr 2011 14:29:44 - 2.167.2.13
@@ -2891,7 +2891,234 @@
* @param isElf64 is this an ELF64 symbol?
*/
#if defined(HAVE_GELF_H) defined(HAVE_LIBELF) !defined(__FreeBSD__)
-static char * sonameDep(/*@returned@*/ char * t, const char * s, int
isElf64)
+#if defined(RPM_VENDOR_MANDRIVA)
+static char * sonameDep(/*@returned@*/ char * t, const char * s, int
isElf64, int devel, int uClibc)
+/*@modifies t @*/
+{
+char *tmp = t;
+*t = '\0';
+if (uClibc)
+tmp = stpcpy(tmp, uClibc();
+if (devel) {
+tmp = stpcpy(tmp, devel();
+}
+#if !defined(__alpha__) !defined(__sun)
+if (!isElf64) {
+/* XXX: eehhk, would've been nice with consistency, mandriva legacy...
:| */
+if (!devel s[strlen(s)-1] != ')')
+(void) stpcpy( stpcpy(tmp, s), ()(64bit));
+else {
+tmp = stpcpy(tmp, s);
+if (devel)
+tmp = strstr(t, .so);
+tmp = stpcpy(tmp, (64bit));
+}
+}else
+#endif
+tmp = stpcpy(tmp, s);
+if (devel) {
+char *suffix = strstr(t, .so);
+if (suffix)
+tmp = suffix;
+tmp = stpcpy(tmp, ));
+}
+if (uClibc)
+tmp = stpcpy(tmp, ));
+
+return t;
+}
+
+static char *find_elf_interpreter(GElf_Ehdr *ehdr, Elf *elf, char *filename)
+{
+FILE *fp = NULL;
+struct stat statbuf;
+GElf_Ehdr ehdr_mem;
+GElf_Shdr shdr_mem, *shdr;
+GElf_Phdr phdr_mem, *phdr;
+GElf_Dyn dyn_mem, *dyn;
+Elf_Data * data;
+Elf_Scn *scn = NULL;
+int fdno;
+char *interp_name = NULL;
+char *libpath = NULL;
+int cnt;
+int class;
+size_t shstrndx;
+
+if (filename) {
+if (!(fp = fopen(filename, r))) {
+perror(filename);
+return NULL;
+}
+if (fstat((fdno = fileno(fp)), statbuf) 0) {
+perror(filename);
+goto end;
+}
+if ((size_t) statbuf.st_size sizeof(Elf64_Ehdr) ||
!S_ISREG(statbuf.st_mode))
+goto foo;
+
+(void) elf_version(EV_CURRENT);
+elf = NULL;
+if ((elf = elf_begin (fdno, ELF_C_READ, NULL)) == NULL
+|| elf_kind(elf) != ELF_K_ELF
+|| (ehdr = gelf_getehdr(elf, ehdr_mem)) == NULL
+|| !(ehdr-e_type == ET_DYN || ehdr-e_type == ET_EXEC))
+goto end;
+}
+foo:
+
+if (ehdr-e_type != ET_EXEC ehdr-e_type != ET_DYN) {
+fprintf(stderr, %s: not a dynamic executable\n, filename);
+goto end;
+}
+class = gelf_getclass(elf);
+
+for (cnt = 0; cnt ehdr-e_phnum; cnt++) {
+phdr = gelf_getphdr (elf, cnt, phdr_mem);
+if (phdr-p_type == PT_INTERP)
+break;
+phdr = NULL;
+}
+if (phdr) {
+
Re: [CVS] RPM: rpm-5_3: rpm/ CHANGES rpm/lib/ rpmds.c
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 = (0x7fff68dff000) libc.so.0.9.30.3 = /usr/uclibc/lib64/libc.so.0.9.30.3 (0x7f99798ff000) ld64-uClibc.so.0.9.30.3 = /usr/uclibc/lib64/ld64-uClibc.so.0.9.30.3 (0x7f99796f7000) 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.. :| Revert. Would you prefer for the patches to be maintained locally in cooker svn rather than under mandriva #ifdef? And get the fiddle ups in lib/psm.c for triggers removed as well. Will do when I get there. 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 Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_3: rpm/ CHANGES rpm/lib/ rpmds.c
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 = (0x7fff68dff000) libc.so.0.9.30.3 = /usr/uclibc/lib64/libc.so.0.9.30.3 (0x7f99798ff000) ld64-uClibc.so.0.9.30.3 = /usr/uclibc/lib64/ld64-uClibc.so.0.9.30.3 (0x7f99796f7000) 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 Managerhttp://rpm5.org Developer Communication Listrpm-devel@rpm5.org smime.p7s Description: S/MIME cryptographic signature
Re: [CVS] RPM: rpm-5_3: rpm/ CHANGES rpm/lib/ rpmds.c
2011/4/16 Jeff Johnson n3...@mac.com:
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 = (0x7fff68dff000)
libc.so.0.9.30.3 = /usr/uclibc/lib64/libc.so.0.9.30.3
(0x7f99798ff000)
ld64-uClibc.so.0.9.30.3 =
/usr/uclibc/lib64/ld64-uClibc.so.0.9.30.3 (0x7f99796f7000)
Note that the ldd will _ALWAYS_ display DT_NEEDED - DT_SONAME linkages
because that is in fact exactly the ELF feature:
Identical SONAME == Identical content
when usual library conventions are done correctly (i.e.
different/incompatible content
always has different soname).
The example you gave is exactly what is _SUPPOSED_ to happen.
I'm almost certain that is even the intent: so that uClibc can interoperate
with existing ELF libraries.
No, for uClibc there's a complete toolchain for it living under
/usr/uclibc, which
has it's own elf interpreter
(/usr/uclibc/{lib/ld-uClibc.so.0,lib64/ld64-uClibc.so.0})
which everything is linking against and the libraries aren't anywhere
near ABI compatible, they might even be built with different options.
Now for the package dependencies: You (or Mandriva) wish different policy for
packages
than how ELF SONAMES are used. If the example you gave using
Requires: libz.so.1()(64bit)
doesn't Just Work from all ELF executables, well that's no problem that
could or should be fixed with Yet More Package Dependencies like
Requires: uClibc(libz)
It is in fact not even the right goal to add dependencies to prevent
uClibc packages from using whatever ELF libraries are available.
No, that won't work, uClibc lives in a separate root that is not in the standard
library paths, it has a separate elf interpreter which everything links against,
and to make sure everything works outside the uClibc's root
(/usr/uclibc) as well,
rpaths are used.
Determining whether uClibc or not based on the elf interpreter used is
if anything
the closest you'll get to right, considering this is how the linker
actually behaves.
If Mandriva truly wants to segregate uClibc - other ELF linkages, then the
proper way to do that is to change the SONAMES to ensure that indeed, uClibc
links only uClibc specific libraries. It isn't terribly hard to
change the linkage line to make that happen.
Considering the idea is to maintain a complete toolchain with several shared
libraries etc., the headaches of changing SONAME and adjusting any dependencies
accordingly should be rather obvious.
If you want preference of uClibc dependent packages, well that can be done
too, just not in the ELF code in RPM. There's lots of ways to add dependencies
without scrapping-and-replacing (the _ONLY_ serious difference is a
readlink(2)
call to follow a symlink gawd knows where before doing what RPM is already
doing
with ELF dependencies, the rest is just strings) the existing mechanism in
RPM.
Wrong, if you take a closer look at the code, you'll see that the
result of readlink()
placed on 'path' is never even used currently.
I'll be commenting out this code for now to avoid any further
confusion concerning
this..
Notice that the devel() dependencies generated does *not* add any dependencies
on any of the SONAME packages/provides at all and has *nothing* to
do/relate with
the current automatic symlink dependencies in place either
All of the above comments apply equally to devel(...) and uClibc(...)
namespaces.
Figure out some other means than scrapping-and-replacing the ELF dependency
code generation to do whatever you wish
You're wrong in the assumptions made both wrt. devel() and uClibc(),
meaning that
I've either not written the code clearly enough, and/or caused by the
obvious lack
of documentation.
I will document this through blueprints on launchpad in the not so
distant future as
soon as I find the time.
--
Regards,
Per Øyvind
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
Re: [CVS] RPM: rpm-5_3: rpm/ CHANGES rpm/lib/ rpmds.c
On Apr 16, 2011, at 1:49 PM, Per Øyvind Karlsen wrote: No, for uClibc there's a complete toolchain for it living under /usr/uclibc, which has it's own elf interpreter There's the answer: A dependency on a separate interpreter (presumably you mean loader) is needed. and stop with this uClibC(...) namespace fiction through symlinks. 73 de Jeff smime.p7s Description: S/MIME cryptographic signature
