[Rpm-maint] Interested in helping...
James Olin Oden
james.oden at gmail.com
Fri Dec 15 21:20:58 UTC 2006
I just recently got the news about this new fork() of rpm meant to be
"the" upstream source of rpm for vendors. Frankly, I think this has
been waiting far too long and am happy to see it. That being said I
would definately like to be a part of this and help in anyway I can,
as a representitive for my company which operates in the telophony
To wit I figured I should list the sort of things that I/we are interested in:
- continue to enhance and harden the rollback mechanism.
- add tools to help manage rollbacks.
- complete perl bindings, capable of:
- driving builds.
- distribution analysis.
- better build API (haven't thought too deeply about this, but I know
I would like to
from an API perspective drive rpm builds).
- continue to harden pre-transactional checks.
- better automatic dependency detection.
- help rpm become a more intuitive tool to use (vague, I know)
- drill in some sane way to allow for alternate policies within rpm.
- continue to harden rpm in general.
Anyway, I can't say that any decision has been made to go with this
version of rpm versus any other version yet, but I do very much like
the idea of there being a reasonably supported upstream version that
is backed by major vendors, and I would like to help with that in any
I think the first thing I could probably start helping with is picking
up where Chip Turner left off with the perl bindings. Rollbacks is
another discussion that we could deal with later. I haven't read all
the information on your source control but I'll look at that and
probably have questions.
Is the help welcome?
More information about the Rpm-maint