I'm pretty sure this bug didn't exist when I tested against GIT, but it seems if you include a class twice, Puppet barfs (both 0.24.0 and 0.24.1). I suspect it was broken before 0.24.0 was cut but after I tested.
<0> sa_dewha@engpsr0142.intranetdev.barcapdev.com (0 jobs)
/users/unix/sa_dewha/SVNCheckOut/bootstrap/puppet/modules/ytest/examples
% sudo ./test.sh
Password:
++ pwd
+ MODULEDIR=/users/unix/sa_dewha/SVNCheckOut/bootstrap/puppet/modules/ytest/examples/../..
+ puppet --color=false -v --no-report --server=localhost --modulepath=/users/unix/sa_dewha/SVNCheckOut/bootstrap/puppet/modules/ytest/examples/../.. --libdir=/var/lib/puppet/plugins ./setup.pp
info: Autoloaded module ytest
notice: Scope(Class[ytest::setup]): YTEST
info: Autoloaded module xtest
notice: Scope(Class[xtest::setup]): XTEST
Resource Class[xtest::setup] is already defined
<1> sa_dewha@engpsr0142.intranetdev.barcapdev.com (0 jobs)
/users/unix/sa_dewha/SVNCheckOut/bootstrap/puppet/modules/ytest/examples
On 0.23.2 it works:
<0> sa_dewha@engpsr0000.intranetdev.barcapdev.com (0 jobs)
/users/unix/sa_dewha/SVNCheckOut/bootstrap/puppet/modules/ytest/examples
% sudo ./test.sh
++ pwd
+ MODULEDIR=/users/unix/sa_dewha/SVNCheckOut/bootstrap/puppet/modules/ytest/examples/../..
+ puppet --color=false -v --no-report --server=localhost --modulepath=/users/unix/sa_dewha/SVNCheckOut/bootstrap/puppet/modules/ytest/examples/../.. --libdir=/var/lib/puppet/plugins ./setup.pp
info: Loading fact lomfacts
info: Loading fact hwfacts
info: Loading fact swap
info: Loading fact roothome
info: Loading fact virtual
info: Loading fact installed_kernels
info: Loading fact blastwave
info: Loading fact build_details
info: Loading fact satellite
info: Autoloaded module ytest
notice: ytest::setup: YTEST
info: Autoloaded module xtest
notice: xtest::setup: XTEST
<0> sa_dewha@engpsr0000.intranetdev.barcapdev.com (0 jobs)
/users/unix/sa_dewha/SVNCheckOut/bootstrap/puppet/modules/ytest/examples
Alas we use this facility extensively to instantiate resources that are required by multiple modules. If File X is a dependency of module Y and module Z, typically we'll include modulex::subsection in both module Y and Z. This preserves our ability to run each module alone (and pull in the subsection) and also for the entire configuration to compile with unique resources.
Therefore our configuration doesn't work against either 0.24.0 or 0.24.1.
I will upload the two modules as an attachment.
I found this when trying out your configuration compiling idea from IRC.
Regards,
Derek