On Sat, Jan 28, 2006 at 09:34:09AM -0800, Tyler MacDonald wrote: > > From what I gather, CPANPLUS is a linear package building > system, whereas YACsmoke is a wrapper around that that tries to build as > many packages as is humanly (er, computerly) possible on a system, with the > side effect of sending it's results through Test::Reporter. YACsmoke also > can maintain a database of what it has built and what it hasn't, allowing a > YACsmoke system to eventually exhaustively build every single package on > CPAN without building the same one twice. Is this correct?
Sort of. CPANPLUS also maintains a database for the current run, so if you have a list of 20 distributions you are testing, if 5 of those have a prerequisite for the same distribution, CPANPLUS internally only makes/tests it once, but adding each distribution path to @INC. However, the state information that CPANPLUS stores doesn't include the test result of a distribution. CPAN::YACsmoke on the other hand, does record the test result. This means that if it tried to build a distribution (currently checks agains the latest version), which reports a FAIL or NA, any distribution that requires it will have their test results graded as ABORTED and NA respectively. The ABORTED result does not get reported to CPAN Testers. The part that is missing currently, is that if a distribution that is a prerequisite now PASSes, there is no code to actively change all those ABORTED to NONE, so that the requiring distribution can be retested. This is part of my todo list. > > What would the plugins for .deb, .rpm and .ppm do? Currently we just > > pass the path to CPANPLUS and let CPANPLUS unwrap, make and test the > > distribution. We then just interrogate the results. > > These plugins would execute *after* YACsmoke/CPANPLUS has done it's > work, but before it's cleaned up after itself, and generate the actual > .deb/.rpm/.ppm files. I would see this as a different system, perhaps for someone who actively maintains a repository for that particular install package. I would prefer to see a code base that uses the YACSmoke database, rather than used as a plugin. The .cpanplus build directories are not removed once testing is complete, so the blib directories are all still available after a test run. YACSmoke does provide a purge facility, but it doesn't run automatically after a test run, you have to manually instigate it. > > Perhaps this is something you meant for CPANPLUS to handle, in which > > case I'm sure that's something Jos would be interested in, as he has > > previously looked at some kind of binary support. > > Well, maybe the actual low-level package generation could be kicked > down a level, but the whole reason I thought of using YACsmoke for this was > because of it's "grab everything and try to build it" nature. YACSmoke would certianly be useful as a first stage, to ensure you only package distributions that pass the tests for your platform. > > I plan to find time soon to complete the tests required for the next > > release of CPAN::YACSmoke, so if what you want does relate to > > CPAN::YACSmoke I can start taking a look and see what needs to be done > > to implement it. I will look into this further, but it'll be lower on my todo list, as it will be driven by packagers rather than testers. Barbie.
