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=5047&alloc_id=10808&op=click _______________________________________________ unattended-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unattended-devel
