Re: [CVS] RPM: rpm/ CHANGES macros.in

2008-04-10 Thread Anders F Björklund
Jeff Johnson wrote: I have multip[le issues with changes like this: 1) the patch uses envvar's Using envvar's forces remote rpm to carry an environment along in order to run remote commands, and largely forces remote execution with shell. There are many times/places that

Re: [CVS] RPM: rpm/ configure.ac macros.in

2008-04-10 Thread Anders F Björklund
And the feeping creaturism starts to try to accomodate automatic detection for a functionality that isn't needed or used by rpmbuild itself. Feel free to revert... It was just that proyvind's original implementation returned RPM_BUILD_NCPUS = undefined here. :-) And what happens in a VM,

Re: Trying to understand RPM 5 vs RPM 4 Conflicts handling

2008-04-10 Thread devzero2000
Two possibilities exist in order to face the problem in a correct way- in rpm 4 e rpm 5 - , imho - i use it both: 1 - The two(or more) package go in conflicts in the files that compose them : pac1 -- Version : 1.0 Release: 1 Provides: pac = %{version} -%{release} Obsolets : pac

Re: Trying to understand RPM 5 vs RPM 4 Conflicts handling

2008-04-10 Thread Jeff Johnson
On Apr 10, 2008, at 8:29 AM, devzero2000 wrote: Also this reference could be useful, besides that something is based on some rpm patch not upstream, imho: http://en.opensuse.org/Upgrade_Dependencies What do you think ? Let me speak to the general issue(s) first. The issue of a self-

Re: [CVS] RPM: rpm/ CHANGES macros.in

2008-04-10 Thread Jeff Johnson
On Apr 10, 2008, at 11:09 AM, Per Øyvind Karlsen wrote: På Torsdag 10 april 2008 , 13:39:57 skrev Anders F Björklund: Jeff Johnson wrote: I have multip[le issues with changes like this: 1) the patch uses envvar's Using envvar's forces remote rpm to carry an environment along

Re: [CVS] RPM: rpm/ CHANGES macros.in

2008-04-10 Thread Per Øyvind Karlsen
På Torsdag 10 april 2008 , 13:39:57 skrev Anders F Björklund: Jeff Johnson wrote: I have multip[le issues with changes like this: 1) the patch uses envvar's Using envvar's forces remote rpm to carry an environment along in order to run remote commands, and largely forces remote

Re: [CVS] RPM: rpm/ CHANGES macros.in

2008-04-10 Thread Per Øyvind Karlsen
På Torsdag 10 april 2008 , 17:19:38 skrev Jeff Johnson: On Apr 10, 2008, at 11:09 AM, Per Øyvind Karlsen wrote: På Torsdag 10 april 2008 , 13:39:57 skrev Anders F Björklund: Jeff Johnson wrote: I have multip[le issues with changes like this: 1) the patch uses envvar's Using envvar's

Re: [CVS] RPM: rpm/ CHANGES macros.in

2008-04-10 Thread Jeff Johnson
On Apr 10, 2008, at 11:38 AM, Per Øyvind Karlsen wrote: På Torsdag 10 april 2008 , 17:19:38 skrev Jeff Johnson: On Apr 10, 2008, at 11:09 AM, Per Øyvind Karlsen wrote: På Torsdag 10 april 2008 , 13:39:57 skrev Anders F Björklund: Jeff Johnson wrote: I have multip[le issues with changes

Re: [CVS] RPM: rpm/ CHANGES macros.in

2008-04-10 Thread Michael Jennings
On Thursday, 10 April 2008, at 09:49:16 (+0200), Per ?yvind Karlsen wrote: +%_initrddir%{_sysconfdir}/rc.d/init.d Can anyone explain to me why this macro is initrddir when /etc/init.d and /etc/rc.d/init.d have absolutely nothing whatsoever to do with the initial RAM disk?

Re: [CVS] RPM: rpm/ CHANGES macros.in

2008-04-10 Thread Jeff Johnson
On Apr 10, 2008, at 12:37 PM, Michael Jennings wrote: On Thursday, 10 April 2008, at 09:49:16 (+0200), Per ?yvind Karlsen wrote: +%_initrddir %{_sysconfdir}/rc.d/init.d Can anyone explain to me why this macro is initrddir when /etc/init.d and /etc/rc.d/init.d have absolutely

Re: [CVS] RPM: rpm/ CHANGES macros.in

2008-04-10 Thread Per Øyvind Karlsen
På Torsdag 10 april 2008 , 17:55:05 skrev Jeff Johnson: Not true. There are already Packaging Policy Police and you have   chosen a macro name that falls within their claimed territority, and are going to   attempt to populate that macro with values that are generally useful, rather than  

Re: [CVS] RPM: rpm/ CHANGES macros.in

2008-04-10 Thread Jeff Johnson
On Apr 10, 2008, at 1:08 PM, Per Øyvind Karlsen wrote: På Torsdag 10 april 2008 , 17:55:05 skrev Jeff Johnson: Not true. There are already Packaging Policy Police and you have chosen a macro name that falls within their claimed territority, and are going to attempt to populate that macro with

Re: [CVS] RPM: rpm/ CHANGES macros.in

2008-04-10 Thread Jason Corley
On Thu, Apr 10, 2008 at 12:37 PM, Michael Jennings [EMAIL PROTECTED] wrote: On Thursday, 10 April 2008, at 09:49:16 (+0200), Per ?yvind Karlsen wrote: +%_initrddir%{_sysconfdir}/rc.d/init.d Can anyone explain to me why this macro is initrddir when /etc/init.d and

Re: [CVS] RPM: rpm/ CHANGES macros.in

2008-04-10 Thread Anders F Björklund
Jeff Johnson wrote: Can anyone explain to me why this macro is initrddir when /etc/init.d and /etc/rc.d/init.d have absolutely nothing whatsoever to do with the initial RAM disk? Shouldn't it be initdir? Hysterical accident is what my bleached neurons remember. Either Mandriva or PLD was

Re: [CVS] RPM: rpm/ CHANGES macros.in

2008-04-10 Thread Anders F Björklund
It was Mandriva, says the changelog: http://rpm5.org/cvs/filediff?f=rpm/platform.inv1=2.6v2=2.7 Couldn't find their original changelog, seems like it was reset at 2005 or so ? Didn't look hard enough: * Mon Aug 21 2000 Frederic Lepied [EMAIL PROTECTED] 3.0.5-11mdk - added _initrddir macro to

rpm uclibc support

2008-04-10 Thread Nigel Kukard
These two patches add support for building rpm5 under uclibc. -N diff -ur rpm-4.4.9_vanilla/rpmio/fts.c rpm-4.4.9_uclibc-ifdefs/rpmio/fts.c --- rpm-4.4.9_vanilla/rpmio/fts.c 2007-01-21 15:18:00.0 + +++ rpm-4.4.9_uclibc-ifdefs/rpmio/fts.c 2008-03-22 13:26:40.0 + @@ -34,6

Re: rpm uclibc support

2008-04-10 Thread Ralf S. Engelschall
On Thu, Apr 10, 2008, Nigel Kukard wrote: These two patches add support for building rpm5 under uclibc. Except for the #include features.h it would be ok. But the features.h is a GLIBC specific thing and hence cannot be included unconditionally... Ralf S.

Re: rpm uclibc support

2008-04-10 Thread Nigel Kukard
These two patches add support for building rpm5 under uclibc. Except for the #include features.h it would be ok. But the features.h is a GLIBC specific thing and hence cannot be included unconditionally... Can we then ifdef it for glibc and uclibc? or just uclibc ... there are some