(note: I haven't looked at the patches yet, will get there in the  
next day or so.
Many of the issues have been around forever, my comments are based on
experience, not from examination of patches. Apologies if I miss  
something ...)


On Oct 7, 2007, at 10:42 AM, Bernhard Rosenkraenzer wrote:

> Hi,
> this is the patches we're applying in Ark Linux - some are  
> generally useful.
>
> rpm-arkvendor.patch
> 	Recognizes Ark Linux and sets RPMCANONVENDOR accordingly
>

Perfect.

> rpm-bs-implies-nodeps.patch
> 	Makes rpm -bs imply --nodeps -- Rationale: To generate the src.rpm  
> only
> 	(e.g. to run the actual build process on another machine), the  
> libraries etc.
> 	in BuildRequires aren't needed, so it shouldn't error out.
>

The eventual solution to the problem is to generate a srpm  
immediately after
parse, before checking build dependencies.

Meanwhile a popt alias to add --nodeps to -bs fixes the problem  
rather easily

(untested /etc/popt or ~/.popt entry, the fix should be exactly this  
simple)

     rpmbuild alias -bs -bs --npdeps

> rpm-create-pentiumdirs.patch
> 	Create pkgsrcdir/RPMS/pentium{3,4} on x86
>

Configgery should be bundled into the cpu-os-macros.tar.gz too.

> rpm-multiple-filesFiles.patch
> 	Allow for multiple %files -f files - usage example:
> 	%find_lang whatever
> 	%find_lang anotherIncludedApp
> 	find $RPM_BUILD_ROOT%_datadir |sed -e "s,^$RPM_BUILD_ROOT,,"  
> >dataFiles
> 	%files -f whatever.lang,anotherIncludedApp.lang,dataFiles
>
> 	Granted, you could also just cat the files together and use -f the  
> result,
> 	but I think allowing several files makes the spec files more readable
>

There are several variant find_lang patches floating around that should
be added.

> rpm-DB_PRIVATE.patch
> 	We've run into db locking problems that fixed themselves with
> 	rpm /var/lib/rpm/__db* so often that we've decided to just get rid  
> of the
> 	__db* files (by using the DB_PRIVATE flag). Not sure if this is  
> the right
> 	fix, but it's a working workaround and so far we haven't seen any  
> drawbacks.
>

DB_PRIVATE is the right fix iff you supply alternative means of
shared/exclusive locking.

WIthout more details, I cannot suggest better alternatives.

> rpm-perl-requires.patch
> 	Filters out perl(the) and perl(this) requirements
>

Hint: Try checking for perl(...) dependency closure with an "everything"
install by doing
     /usr/lib/rpm/rpmdeps -v --perl

There is always a risk of regression wrto the regexes extracted
from perl source files when fiddling with the extractors, so I usually
just ignore spot fixes. OTOH, its way past time for distro-wide reliable
perl(...) dependencies.

> rpm-optional.patch
> 	Adds a "%optional" flag to a file -- that causes the file to be  
> packaged if
> 	it is there, but not to error out if it isn't there.
> 	We're using this e.g. in the context of packaging arch specific  
> headers in
> 	the gcc package (we prefer %optional xmmintrin.h over %ifarch %ix86
> 	xmmintrin.h %endif in that context because the former does the  
> right thing
> 	on any new arch that has xmm intrinsics as well, without having to
> 	explicitly support it).
>

Nice.

> We used to apply some more patches to rpm versions from rpm.org  
> that seem to
> be obsolete in rpm5.org - such as making sure a pentium3 package  
> can be
> installed on pentium4 and athlon (compatible, just not optimal).  
> This touched
> the CPU detection stuff in lib/rpmrc.c, which isn't there anymore  
> in rpm5 -
> if the patch is still needed (haven't checked yet), it'll need to  
> be redone.
> <rpm-arkvendor.patch>
> <rpm-bs-implies-nodeps.patch>
> <rpm-create-pentiumdirs.patch>
> <rpm-multiple-filesFiles.patch>
> <rpm-DB_PRIVATE.patch>
> <rpm-perl-requires.patch>
> <rpm-optional.patch>

TODO++, will vet the patches this week.

73 de Jeff