The solver will be executed on a virtual machine that simulates a GNU/Linux host of architecture x86, 64 bit, single-processor. The OS running on the virtual machine is debian squeeze with security updates.
The version of all available software, if not specified, is equal to the version of the software present in debian squeeze with security updates.
On the virtual machine are installed:
A standard POSIX environment. In particular a POSIX-compatible
shell, which may be invoked by /bin/sh
, will be available, as well
as a GNU Bourne-Again SHell (invoked as /bin/bash
).
A Java Runtime Environment (JRE) 6; the Java application launcher can be
invoked as /usr/bin/java
.
A Python 2.6 environment; the main Python interpreter can be
invoked as /usr/bin/python
.
No other libraries, for any programming language, can a priori be assumed to be available on the system. That means:
Solvers prepared using compilers supporting compilation to ELF
must be submitted as statically linked ELF binaries. No
assumptions can be made on available shared libraries
(so
) on the system.
Solvers written in some (supported) interpreted language must use
the usual shebang lines (#!/path/to/interpreter
) to
invoke their interpreter.
Solvers written in Java must be wrapped by shell scripts invoking the Java application launcher as needed.
Solvers needing other kind of support must make specific arrangements with the competition organizers before the final submission.
The solver execution will be additionally constrained by the following
limits (as implemented by ulimit
):
The execution time is cpu time, measured in the same way as ulimit
-t
. The signal SIGUSR1 will be sent to the solver process and all
its sub processes some time before the timeout. The moment when the
signal is sent depends on the track. It is the responsibility of the
solver to catch that signal, produce an output, and terminate
normally. The utility runsolver
used to enforce these limits can be
downloaded as : git clone
http://mancoosi.org/~abate/repos/runsolver.git/
The solver will be executed with its absolute pathname (like /path/to/the/solver) from an arbitrary point of the filesystem.
The solver directory will be read-only: the solver will not have the right to create new files in this directory, or to write to files in that directory. The environment variable $TMPDIR will be set to reflect the location of a read-write temporary directory. All temporary files must be written in the temporary directory which will be removed after the execution. All other parts of the filesystem must be considered as read-only.
In the "paranoid" track, the solver will be called with 2 command line
arguments: cudfin
and cudfout
, in this order. Both arguments are
absolute file systems paths.
cudfin
points to a complete CUDF 2.0 document,
describing an upgrade scenario. The CUDF document will be
encoded as ASCII plain text, not compressed. The CUDF 2.0
format is specified here.
According to the specifications, the document will consist
of an optional preamble stanza, followed by several package
stanzas, and ended by a request stanza.
cudfout
points to a non-existing file that
should be created by the solver to store its result.
In the "user" tracks, the solver will be called with three command
line arguments: cudfin
, cudfout
, and criterion
, in this
order. The first two arguments are as above, the criterion
argument describes the optimization criterion. The criterion is a
non-empty and comma-separated list of signed function names. Each
sign is either "+" or "-", and each function is as described in
the detailed description of the optimization criteria.
The solver's standard output may be used to emit informative messages about what the solver is doing.
If the solver is able to find a solution, then it must:
write to cudfout
the solution encoded in CUDF
syntax as described in Appendix B of the
CUDF 2.0 specification;
exit with an exit code of 0.
If the solver is unable to find a solution, then it must:
write to cudfout
the string "FAIL" (without
quotes), possibly followed by an explanation in subsequent lines
(lines are separated by newline characters, ASCII 0x0A);
exit with an exit code of 0.
All exit codes other than 0 will be considered as indications of unexpected and exceptional failures not related to the inability to find a solution.