Agh I didn't realize this was specific to the devel package settings.  It 
should still likely be wrapped in the if Mandriva, but it now makes a lot more 
sense to me.



On Apr 10, 2011, at 8:06 AM, "Per Øyvind Karlsen" <pkarl...@rpm5.org> wrote:

> 2011/4/10 Hatle, Mark <mark.ha...@windriver.com>:
>> See below inline
>> 
>> 
>> 
>> On Apr 9, 2011, at 11:57 PM, "Per Øyvind Karlsen" <pkarl...@rpm5.org> 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:   10-Apr-2011 08:57:24
>>>  Branch: rpm-5_4                          Handle: 2011041006572300
>>> 
>>>  Modified files:           (Branch: rpm-5_4)
>>>    rpm/lib                 rpmds.c
>>> 
>>>  Log:
>>>    filter out some redundant devel(...) dependencies
>>> 
>>>  Summary:
>>>    Revision    Changes     Path
>>>    2.170.2.7   +23 -10     rpm/lib/rpmds.c
>>>  
>>> ____________________________________________________________________________
>>> 
>>>  patch -p0 <<'@@ .'
>>>  Index: rpm/lib/rpmds.c
>>>  
>>> ============================================================================
>>>  $ cvs diff -u -r2.170.2.6 -r2.170.2.7 rpmds.c
>>>  --- rpm/lib/rpmds.c    10 Apr 2011 06:05:58 -0000    2.170.2.6
>>>  +++ rpm/lib/rpmds.c    10 Apr 2011 06:57:23 -0000    2.170.2.7
>>>  @@ -2904,21 +2904,19 @@
>>>       if (!devel && s[strlen(s)-1] != ')')
>>>       (void) stpcpy( stpcpy(tmp, s), "()(64bit)");
>>>       else {
>>>  -        char *suffix;
>>>           tmp = stpcpy(tmp, s);
>>>  -        if (devel && (suffix = strstr(t, ".so")))
>>>  -        tmp = suffix;
>>>  +        if (devel)
>>>  +        tmp = strstr(t, ".so");
>>>           tmp = stpcpy(tmp, "(64bit)");
>>>           }
>>>       }else
>>>   #endif
>>>       tmp = stpcpy(tmp, s);
>>>       if (devel) {
>>>  -    char *suffix;
>>>  -    tmp = stpcpy(tmp, s);
>>>  -    if (devel && (suffix = strstr(t, ".so")))
>>>  +    char *suffix = strstr(t, ".so");
>>>  +    if (suffix)
>>>           tmp = suffix;
>>>  -    (void) stpcpy(tmp, ")");
>>>  +    tmp = stpcpy(tmp, ")");
>>>       }
>>> 
>>>       return t;
>>>  @@ -3282,8 +3280,16 @@
>>>       int skipR = (flags & RPMELF_FLAG_SKIPREQUIRES);
>>>       int lnklen;
>>>       char path[MAXPATHLEN];
>>>  +    /*
>>>  +     * We filter out these as they come with glibc, making dependencies on
>>>  +     * them rather redundant.
>>>  +     */
>>>  +    const char *filterRequires[] = {"ld-linux", "ld64-linux" 
>>> "libBrokenLocale.so",
>>>  +    "libanl.so", "libc.so", "libcidn.so", "libcrypt.so", "libdl.so", 
>>> "libm.so",
>>>  +    "libnsl.so", "libnss_compat.so", "libnss_dns.so", "libnss_files.so",
>>>  +    "libnss_hesiod.so", "libnss_nis.so", "libnss_nisplus.so", 
>>> "libpthread.so",
>>>  +    "libresolv.so", "librt.so", "libutil.so", "libthread_db.so"};
>>>       ARGV_t deps = NULL;
>>>  -    size_t nb = strlen(fn);
>>> 
>> 
>> Filtering out the items below on embedded systems can break things (if I'm 
>> understanding the code right)...  In many embedded systems we use eglibc 
>> which is configurable, we also some times break up the libc package into 
>> many small sub packages so that we can only bring in the libraries that are 
>> actually being used.
> Yeah, I did initially do it more minimally, and certainly when splitting up
> the libraries in multiple packages, it might easily become a source of grief.
> 
> But remember that this is only for devel() dependencies, usually you
> don't bother splitting
> up the -devel packages that much as you'd might desire to do with the
> library packages..
> 
> This is an initial implementation ported from bash scripts in mandriva
> though, so
> there's certainly gonna be some rough edges.. ;)
> 
> --
> Regards,
> Per Øyvind
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> Developer Communication List                        rpm-devel@rpm5.org
______________________________________________________________________
RPM Package Manager                                    http://rpm5.org
Developer Communication List                        rpm-devel@rpm5.org

Reply via email to