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
_______________________________________________
users mailing list
[email protected]
http://lists.repoforge.org/mailman/listinfo/users
