[users] [OT] Analogies to "governance, " not so much "manufacturer" -- WAS: EPEL

Jeff Johnson n3npq at mac.com
Mon Jun 27 15:38:33 CEST 2011


Disclaimer: I care only for the engineering not the hysterical politics.

On Jun 27, 2011, at 8:27 AM, Dag Wieers wrote:

> 
> So there were a few problems that made us decide not to join the Fedora 
> project at that time:
> 
>  - They were not interested in RHEL packages
> 
>  - They were not interested in using macros to simplify supporting
>    multiple distributions
> 
>  - They were not interested in using the %dist macro
> 


Let me restate your hysterical interests positively:

   - commercially useful "production" quality software distribution.

	Enterprise software has long-term maintenance/upgrade/backport issues
	that linux distros have never addressed well, but RPMforge (and you) have.
	Linux distro packaging policy is typically
		Security fixes only.
	in order to avoid the non-trivial re-integration costs/risks of
	destabilizing already released software product.

    - software build recipe's that can be maintained persistently and universally.

	By "using macros" you are implicitly stating that a proper abstraction
	to hide differences would lead to a unified build recipe that achieves
	the ideal holy grail of packaging and software distribution:
		Build software anywhere and run binaries everywhere.
	Again RPMForge (and you) are unique imho in the approach through a better
	methodology, not cost/risk avoidance as in "Security fixes only" and
	"Fixed in the next release!" as commonly practiced.

    - an identification scheme that can be used for tracking/accountability.

	While %dist/%repo identification in Release: strings are rather flimsy (jmho),
	there most definitely is a need to identify where/how binaries were built
	so that problem reports and feature requests can be delivered accurately.

>From a rpmbuild engineering POV, these are the flaws:

    - the *.spec parser in rpm build was badly borked up in rpm-2.4.12 in 1997

	Parsers need a grammar not "Have it your own way!" expectations. The
	rpmbuild *.spec parser was tweaked to Get Things Done! and isn't soundly
	implemented.

    - macros used for templating build recipes are per-distro "de facto" dialects.

	While macros/templating are clearly useful (or RPM would have toasted long ago),
	the original motivations for the macro implementation were _NOT_ intended
	for templating, but rather to unify 3 sources of information passed into a build:
		a) per-package build parameters
		b) per-build system parameters
		c) per-instance command line parameters
	What is/was missing (and what you seek imho) is an explicit design to
	address the needs of abstracting away and hiding build differences.

    - Release: was intended as a simple build++ counter, not for %{?dist} identification.

	There are so many sources in need of identification these days that appending
	strings to a Release: to indicate how/where software was processed simply
	isn't sufficient. The deeper design flaw is that the markers added to
	Release: for identification purposes are propagating into "dependency hell"
	and breaking upgrades again and again and again for no obvious benefit.

Better engineering *IS* possible to address the flaws I mentioned. ANd it
can be done in a legacy compatible fashion with different templates, not
more macro madness, in order to achieve
	Build anywhere and run the binaries everywhere.

The ROADMAP for rpm6.org is currently being devised to address some of
the engineering flaws above. The RPMforge (and your) focus on long
term enterprise focussed and maintainable is well known (to me) and
I fully intend to re-use RPMForge *.src.rpm build recipes as de facto
real world test cases for attempting better solutions to more useful
(than *.spec) build recipes.

hth

73 de Jeff

	
	

	



More information about the users mailing list