[Scons-dev] RPM helper functions, where should they go?

Gary Oberbrunner garyo at oberbrunner.com
Tue Sep 25 14:03:41 EDT 2012


On Tue, Sep 25, 2012 at 1:38 PM, Dirk Bächle <tshortik at gmx.de> wrote:

> Hi there,

>

> for fixing the current Buildbot failures I still have to fight down several

> RPM tests. They check the names of the created RPM files


I think many of the current tests are way too strict in how they test
the build output. They could achieve the same goals (success/failure)
but be a lot more resistant to path changes, drive name changes and
even language changes if we just check the output for certain key
words. Plus it makes the tests simpler to create and maintain. Would
that help here?


>, which differ

> depending on the used hardware/os combination.

> I'd like to wrap the original RPM functions for canonicalizing

> machine/system names and all the supporting stuff to a Python module, but I

> can't make up my mind about where the file should go.

> It should be possible to import it from the RPM/packaging stuff and the test

> suite in QMTest as well.

>

> My suggestion would be a new file "rpmrc.py" in the SCons/Tools dir,

> alongside the "rpm.py" tool.

> Does this make sense or do we have a better place?


I think since it is tool-specific, putting it in SCons/Tools is best
-- it shouldn't go up in the core. You could call it rpmutils.py
perhaps?


> P.S.: For cases like this it would be cool to have a "scons-common" package

> with stuff that can get used by SCons itself, the test framework and perhaps

> even Parts. It could offer basic things like "starting processes,

> is-this-a-list?" and similar stuff, which are partly spread over the whole

> codebase in different variations...


Util.py has some of this, but indeed not all of it. In my experience,
trying to define what's "basic" in your sense above is trickier than
it seems. But I also agree there is some duplication that should be
eliminated -- not all that much though, right?

--
Gary


More information about the Scons-dev mailing list