[csw-maintainers] [GAR] RFD: Custom assertions for packages

Maciej (Matchek) Blizinski maciej at opencsw.org
Wed Mar 3 12:22:00 CET 2010


There are certain packages which are susceptible for certain kind of
problems.  For instance, we might make sure that isaexec is not used,
or that a /opt/csw/bin/sparcv9/foo binary is not present, or that a
/opt/csw/lib/libfoo.so library is present in a certain package, or
that file foo is present in CSWfoo_devel and not CSWfoo.

Such issues could be checked either during build, a part of GAR-driven
build process, or later on by checkpkg.  Since the tests I'm thinking
about are package-specific, it's not possible to write generic
checkpkg rules for them.

One kind of checks I can think of is about testing the prototype.  The
GAR interface could look something like this:

ASSERT_PROTOTYPE_CONTAINS_CSWfoo = $(bindir)/foo
ASSERT_PROTOTYPE_ABSENT_CSWfoo = $(bindir)/sparcv9/foo
ASSERT_PROTOTYPE_ABSENT_CSWfoo-devel = .*\.py
ASSERT_PROTOTYPE_CONTAINS_CSWpy-foo = .*\.py

The idea is that the algorithm/code is the same, you only change the
parameters such as package and file names.

I can see two general potential solutions for this kind of checks:

- it gets checked by GAR right after the application of the PKGFILES_*
rules (good because it catches errors early)
- information gets packaged up in the package and then is later used
by checkpkg (good because it's done together with all the other
checks,  the flip side is that it requires an additional communication
layer which is itself prone to errors and must be tested)

Here are some questions:
- Which solution looks better to you and why? How would you implement it?
- What kind of package-specific checks can you think of?

Maciej


More information about the maintainers mailing list