These are ideas which definitely seem like they'd be valuable to some people, but perhaps aren't very satisfactorily formulated. - "Simple Packaging Kit" output support see http://developer.stampede.org/system/spk/ (as a frontend and a backend... maybe) (also: need to decide if we should `spk_build' or just implement it ourself w/ tar and bzip2.. i think we oughta implement it ourselves) This idea has been moved to this list b/c there is no clear spk standard -- in fact, it is under development: they plan on having several more "versions" -- they really are poorly documented. - implement Slava Gorbanev's suggestion for multiple build support in RPM: i suggest use conditional macros, consider following in your .spec: Release: 1%{?debug} # %{?debug} means "substitute %debug expansion if it's not empty, and # nothing otherwise" ... %build ./configure %{?debug:--enable-debug} # similar, this means "substitute string after ':' # if %debug yields non-null, nothing otherwise" # note you could invert condition sense with %{!?debug:something} -- # substitute 'something' if debug IS null. # note also that substituted string can contain macros itself. ... then, "nondebug" package build as usual, while "debugging" should be built with 'rpm --define "debug 1"'. thus you'll get two releases, xxx-1 and xxx-1debug. there are two .src.rpms still, but one .spec for both. I'm not sure this is worth it -- it makes the .spec file very ugly and it very complicated, merely so we have one .spec file? unless the .spec files are simple, it isn't worth it... better to just maintain two .spec files or manually merge if you want to abandon pkgwrite. - warn about installed files that are never used. Currently we have no phase to do this in. Adding one would slow things down a lot.