Max Lovius <[EMAIL PROTECTED]> writes:

> The only solutions I see at the moment is too write a config.pl script that
> checks which installation version is been installed and changes setting in
> the unattend.txt file?
> Seems a little like re-writing.

Don't think of it as re-writing.  Think of it as a very, very, very
flexible configuration file :-).

> Maybe the are some examples of config.pl I could base it on? 

This is a great idea, but we don't have any yet.  This is part of that
whole documentation thing which I have been dodging lately...

> Or Is the a simple way to have multiple setting for different
> installations based on the folders or name of the OS folder os\2000\
> os\XP etc the installation is been installed from?

You can use config.pl to do this.  There are a couple of approaches...

If you just want to make the product key depend on the os type,
a config.pl something like this should do it:

  $u->{'UserData'}->{'ProductID'} =
    sub {
        my $src = $u->{'_meta'}->{'OS_media'};
        if ($src =~ /XP$/) {
            return 'XP-LICENSE-KEY';
        }
        elsif ($src =~ /2000$/) {
            return '2K-LICENSE-KEY';
        }
        else {
            die "Unrecognized OS source directory $src";
        }
    };

  # Indicate successful config.pl
  1;

If you want to load an entire unattend.txt file based on which OS is
being installed, you could use a config.pl something like this:

  my $src = $u->{'_meta'}->{'OS_media'};
  if ($src =~ /XP$/) {
      $u->read ('z:\\site\\unattend-xp.txt');
  }
  elsif ($src =~ /2000$/) {
      $u->read ('z:\\site\\unattend-2k.txt');
  }
  else {
      die "Unrecognized OS source directory $src";
  }

  # Indicate successful config.pl
  1;


The former approach is more "declarative"; the latter is more
"procedural".  The code in the procedural version will execute right
when config.pl is loaded.  In particular, it will prompt for the media
type right away, since it needs it to evaluate $src.  This will happen
even before the disk partitioning question gets asked...  You can hack
around this by adding an artificial dependency, but this message is
already too long.

In contrast, the declarative version will only execute when it is
first needed, which will not be until the ProductID field is being
generated for the real unattend.txt file.

Note that I have not tested any of this code.  If you decide to use it
an encounter problems, let me know and I can help you debug.  Your
suggestion for config.pl examples is a good one, so I need to start
collecting them.

 - Pat


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
unattended-info mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unattended-info

Reply via email to