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

Nico Kadel-Garcia nkadel at gmail.com
Tue Jun 28 14:40:25 CEST 2011


On Mon, Jun 27, 2011 at 9:38 AM, Jeff Johnson <n3npq at mac.com> wrote:
> 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:

Nothing hysterical about these claims. Dag has been very cooperative,
particularly in encouraging. EPEL has been backporting from Fedora,
which is useful, but the package naming issue remains confusing? The
'dtag' versus 'dist' issue, alone, makes RPMforge easier to integrate
and avoid confusing overlaps with existing RHEL, CentOS, or SL
packages.

Don't get me *started* on the uppercase/lowercase package name thing.
and the perl numbering issues (due to the CPAN standard of using
floating point numbes, which no other significant software repo does
that I can find) Let's focus on an easy one: Nagios plugins. Whoever
submitted that to EPEL elected, understandably, to refactor the
nagios-plugins package and separate out various components. This makes
sense: the dependencies for a plugin like the Quake test are hardly
necessary for most production environments.

RPMforge kep thte nagios-plugins package intact. Chaos ensued when
EPEL went to a higher "release" number, and it wound up replacing my
similarly versioned RPMforge packagte and did not include a whole
stack of monitors.


>   - 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:

Please don't overstate. They've been a very useful tool, indeed for
maintaining consistency, and tracking the differences, by using a well
integated code base.

>                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.

Welcome to "the bazaar" of free and open software. I, for one, can't
wait 4 years for the next major release of our favorite upstream
vendor's commercial code base, especially when dealing with system
feature additions (such as perl modules for developers), and such as
Subversion which had glaring performance and security improvements
with version 1.6.x, but which SL 5 was burdened with at version 1.4.x
until the upstream vendor finally gave way after 3 years and updated.
RPMforge had kept up to date, and we all benefitted. (I submitted some
of them of those updates.)

>    - 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.

It's a *start*, and it's a small and effective tweak that gets past
the immediate hurdles. Don't let theoretical perfection prevent doing
work that is good enough right now.

> 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.

And will take 10 years on the current RPM development roadmap, and is
likely to break RPM. Let's not go there.

> 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.

Any hints of what might be on that roadmap? rpm6.org is a blank Mac
hosted webserver that begs for acceptance of an unauthenticated SSL
key, without a hint of data. SL 6 users are held, for normal
stability, at RPM version 4.6, and rpm.org's last comment on a roadmap
is at version 4.6. Even Fedora 15 is at 4.9. There is a long, long,
long way to go before RPM version 6 might see production use, and most
of us need to deal with existing systems for the next 5 years.

This is a great example of where "good enough" engineering, such as
RPMforge's use of 'dtag', can really help keep things working until
and unless a major rebuild occurs. And doing that rebuild is going to
be *hard*, due to the temendous existing code base.



More information about the users mailing list