[Rpm-maint] whither rpmbuild, whither rpm?
R P Herrold
herrold at owlriver.com
Tue Apr 15 22:19:56 UTC 2008
A quote from a post earlier to day piqued by interest:
> The ldconfig hackery in rpm is going away sooner or later,
> what I want to see is some more generic mechanism for
> packages to queue actions to happen at end of the
> transaction. ...
> Several ways to accomplish that, I've just been too busy
> whacking potential buffer overflows and similar fun to have
> a chance to really think about it :)
So write the limited %pre and %post grammar and float a
candidate; without a constrained grammar, it is just tossing a
pail of water into the wind; in the absence of limits or
defined ways to perform permitted operations, continued
deference to a nice Turing complete shell interpreter's bag of
tools doomed transactional rollbacks, and makes avoidance of
'potential' buffer overflows the least of one's worries; an
obfuscated 'ulink' of two in a %pre or %post, or dropped in as
an 'at' script for time delay action, has much higher in the
realm of damage potential.
It seemed to me that chasing 'potential' buffer overflows, on
code that valgrind is largely happy with; I watch all rpm
related filings and have for many years, and frankly, this
asserted concern with code cleanup in the name of avoiding
insecure! buffer! overflows! just looks like makework to me.
So being interested in the future or RPM and RPMBUILD, I
figured, why not go to the source, and look at the rpm.org
website, as 'We're relaunching rpm.org, with a new direction
for future development of RPM. RPM should not be the province
of one company, or a small set of developers' -- edit by:
2007-10-15 10:03:03 by PanuMatilainen
RPM development switches to GIT (Mar 31th 2008)
* Rpm code repository has been converted from Mercurial to
GIT, effective immediately. Access details are documented on
So what, specifically, are you doing with RPM? And where is
the work going to happen?
We have set up a new [WWW] repository, [link to: http://hg.rpm.org/]
When is all of this happening?
Starting now. Planning and review happening over the next 3-6
months -- edit 2006-12-15 23:20:06 by JamesBowes
Build process cleanup
* Clean up, modernize and correct RPM's auto*tool usage
* Make compilation free of warnings
Let's look elsewhere:
by: Panu Matilainen
Sure there's an API of sorts for this in librpmbuild (even if
it's not exactly very sane or friendly to use), ...
NOTABUG in the sense that couple of ways to access this data
do exist. There are plans to provide a saner API for the build
parts for rpm (including python bindings), but that's way way
out of scope for RHEL 5.
well ... Where ARE the asserted 'plans to provide a saner API
for the build parts for rpm (including python bindings)' What
else is slated to be cut out of RPM as 'Remove ancient,
I sure don't see them in a form suseptible to implementation
or comment anywhere at http://www.rpm.org/ -- all I see is
these days is one developer from one company with a
non-visible plan on this tine of the fork.
-- Russ herrold
More information about the Rpm-maint