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 _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
