Steffen,
As for keep modifications through a CVS update - so far, I
haven't (at least not on my first try). So from now on, before updating
my install tree, I'll probably copy my modified scripts to the site
folder, then back again afterwards (to keep prepare in-line). Its been
very hands on. Not to mention the need to manually remove any obsolete
update or install package since (at least in my experience) prepare
doesn't know how to replace the old package (ie. winamp5.03 to 5.05).
Thats another thing for the wish list I suppose.
Perhaps we can make prepare to seek out other scripts wile also using
your the ignore list. Or, like in the case of the unattended.txt file
parse function, let our site's (modified) scripts be used to challenge
any new scripts from cvs, thus creating new and custom scripts
on-the-fly. That way we get both the update and our own config with a
site/xyz.bat that would just have the added or removed functions from
its corresponding script from cvs. I think this would be an additional
task for prepare to do.
If none of that makes sense, or just sounds like I'm repeating you, feel
free to ignore me.
-sp
Steffen Kaiser wrote:
Hello,
I'm just back from a short vacation and fired up a cvs update of
unattended and ran tools/prepare and was told that there is no
scripts file.
The reason is that one is to first cd into ./tools and run
./prepare. I hadn't read the manual well enough, so I ran
./tools/prepare.
Attached is a diff to let both prepare and check run from within any
directory.
===
Then I have the problem that after running cvs update/co, I have all
the packages in scripts again that I do not want to install and,
hence, I do not need to download anything for.
I tried to replace those scripts by zero-length files, so that cvs
update does not re-download the deleted files, but then when they
change, you get plenty of reject-stuff.
I wonder if it would be better to have a persistent state of what
packages and updates are to be downloaded, which is separated from
CVS, e.g.:
variant 1) seen in apache2:
There is both a sites-available and a sites-enabled directory, they
grab configuration data from *-enabled only, but supply and update the
data in *-available only.
So, one could have, say, install/scripts for all maintained scripts;
but prepare and check use the directory install/site/scripts only to
populate the packages and updates directories.
install/site/scripts could be the same as the /etc/rc?.d/--symlinks
to the /etc/init,d/* script.
The disadvantage is that new scripts become active by a manual action
only.
The advantage: No CVS is trying to meddle around with the contents of
the site/ directory, hence, one can savely put own scripts there, even
if their name conflicts with future maintained scripts.
Disadvantage #2: Current scripts might use the path install/scripts
to access other scripts directly.
variant 2) there is an ignore list in install/site
Here: install/scripts contains the maintained scripts and
install/site/ignore the information, which scripts are to be ignored.
Advantage: new scripts become active immediately.
Disadvantage: Own scripts might interfere with future managed scripts.
Thinking about it, it would be also nice to have persistent
modifications to other scripts, e.g. to not install Media Player 9 or
MovieMaker or a selected set of options currently available in
win*-notips.pl.
How does other people keep modifications through a CVS update?
Bye,
---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click
___
unattended-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unattended-devel
