update releases

[+theblazingangel MVC]

This is mainly for the benefit of maxkohl who was asking some questions about using update releases.

Example update contents

update 1

kb123456.amc_files / kb123456.exe

kb123456.amc

kb123456.lst

sunjava_enu.amc

sunjava_enu.lst

update 2

kb123456.amc_files / kb123456

kb123456.amc

kb123456.lst

sunjava_enu.amc_files / sunjava.exe

sunjava-enu.lst

Observations

Installing update 1 on full:

No problems

Installing update 1 on lite:

Partial sunjava module installed means:

- possible crash on load, or

- unofficial module that doesnt work / crashes when selected for installation / partially completes setup instructions (inc possibly adding reg detection entryies).

Using update 1 stand-alone:

If all program files included...

kb123456 works fine

sunjava same as before

Installing update 2 on full:

No problems

Installing update 2 on lite:

Partial sunjava module = just wasted space (no .amc file included in this particular update so no other issues as with update 1)

Using update 2 stand-alone:

If all program files included...

kb123456 works fine

sunjava setup file not used, so you dont have the latest copy installed

Evaluation

Using updates on full releases:

There shouldnt be any problems at all !

Using updates on lite releases:

Problems! we need to prevent installation of any parts of non-lite modules on lite releases.

Solution 1: have two seperate update releases - not my prefered solution, id rather there were not yet more releases to create and derive confusion from.

Solution 2: always include the entire module for modules not in lite releases - not practicle

Solution 3: add option to install script to skip non-lite module files - my preference, i have already just created a working script to do this, and it isnt hard to use!

Note, if for some reason we did include a complete non-lite module, we still shouldnt allow installation because then when we stop installation of parts of the module in the future, they wont have the latest copy of the module installed.

Using updates as standalone:

Problem 1) not all program files included always (~5.5MB)

Solution 1) include them - is this acceptable?

Solution 2) people wanting to use it as standalone should use the latest copy of the autopatcher standalone release to get all the program files, and install the update release on top of it.

Problem 2)

ANY partial module is not going to work.

Fixes introduced through new files will not benefit you because you dont have the complete module to make use of them. this includes:

- replacement of one or more corrupt setup files, or a newer copies

- fixed setup instructions

Solution: never include partial modules, always include the full module. this is probably not very practicle!

Conclusion

The first problem we need to suppress is installation of files/folders for modules not included in lite releases when updating a lite autopatcher installation.

There are two easy solutions:

1) Make two seperate update releases (not my prefered choice), or

2) Use the new nsis script ive created. the user simply selects whether updating a full or a lite installation. if lite is selected, specific files and folders are skipped when extracting. the new page offering this choice is easy to disable when not needed, and specifying files/folders to skip is not that hard, and im confident i can explain it well in the translation-packing documentation.

The other problem is harder to solve, that of using update releases as standalone. first of all you need ~5.5MB of program files. second, you will only be able to use full modules that are included and not partial ones, but its not really practicle.

The solution i propose is that we do neither! ~5.5MB is too much to add really, and by not including it we re-inforce the fact we dont want people to use it for this purpose. however theres an easy solution to this for people like maxkohl who want to - they can simply use the ap-stand-alone download (available in the standalone modules thread) as a base on which to install the update release. and if they choose to do this, then its just tough if they cant use the partial modules, but perhaps where we can, we can chuck in the odd file to make an included module complete, if we think it would be benificial and if the files needed are really small, but the new update modules included should work fine for them.

Comments welcome.

[+M2Ys4U Subscriber¹]

Maybe it's just me but that seemed hard to follow.

Anyways, here are my comments:

I think we should continue with 'half-modules' and just have an alert in the NSIS installer to say that if there is no previous autopatcher directory detected where you wish to extract it, that some modules may not be availible and point them to autopatcher.com and/or this forum to pick up the relevent full or lite release needed.

Maybe with every update release include a 'changelog' file that the installer can check against for patial modules? That would mean a) The user is aware of what files are missing b) is aware that they may be missing out on the majority of patches.

This would seem the most practical way forwards to me.

[maxkohl]

thanks for elaborating...

well, I think that your 3rd solution (skipping) for partial modules over lite installations is really the prefered one.

however, here are my comments:

1. the installer should detect itself whether it has a full/lite folder...practically what M2Ys4U said :)

2. upon uninstallation, user should be given the option to leave a "stub" to load future updates.

3. when leaving such stub, installation folder should be detected as empty regarding to partial modules!

4. if it can help your script in checking existance, identify each module w/unique string/number?

I hope that covers it. I tend to agree w/you on the rest (no need including full modules everytime, let alone huge stubs...why are they so big, anyway?)

You might be interested in implementing the following scheme:

i) having users to download a stand-alone update stub.

ii) publishing sfx modules in a managed list (like the 1st posts every month)

iii) by "sfx" I mean files that extract to AP folder - like current "updates".

iv) the list will offer d/l links (+mirrors) for each hotfix/component (=module)

v) one of the d/l links might be a monthly updated "component list" for the stub.

vi) when stub is launched, it could check existance of critical/additional components.

vii) user will be notified if any critical module is missing, but will be allowed to continue.

pros:

- stub could act as a silent installer for raw "kb*.exe" files - you may simply link to MS...your service will be maintaing an updated and easy (as oppposed to MS) list of needed components, and of course - all the extras of the "full" packages :)

- users may construct a customized build of the modules they want.

- newbies that used WU before, amy only d/l stub + new modules (list should be date-sorted o/c).

cons:

- all these downloads will create a mess, missing AP's point (already noticable with recent updates?).

- partial module updates will be much harder to support this way (could be issued as monthly components, having the stub to install them chronologically - the right order may reside in the "monthly updated components list" suggested above, eliminating the need to tamper with MS's raw hotfix files).

You may not like my idea, but at least the "leave stub" option when uninstalling should be considered IMHO.

Having partial module updates not installed that way, shouldn't create a big problem IMO because if I understand correctly, it doesn't concern to critical hotfixes, but only the full-package's extra components.

[+theblazingangel MVC]

@M2Ys4U

i think detecting the presence of an existing installation could be done, then if a full/lite release is being installed on top the user could be alerted, and if an update release is installed to an empty dir, again the user can be alerted. i'll look into.

your other idea is also something to perhaps consider.

@maxkohl

and option 3 should now be the way forward :D . if it gets too complicated, we can always fall back to two different update release, one for full and one for lite.

it would be nice if we could detect exactly what releases are installed, but i think thats almost impossible to acomplish.

we could use registry entries, and/or a log/database-like file to keep track, but neither would work because of autopatchers portability. registry entries would be left behind, and log/db files could be overwritten when not using the installers to move things around.

if i understand you correctly, i believe the idea your describing is an update system, its been suggested before, and i like the idea, but it would be extremely difficult to do, and its just not likely going to happen.

when uninstalling autopatcher using uninstall.exe, we could give the option to leave a stub (all program files, no modules) behind so that you could use update releases as standalone, but i think that might be a little over complex, when you could keep a copy of the ap standalone handy for that purpose.

i have another small idea, how about adding an autopatcher start menu entry with run autopatcher, and uninstall autopatcher options?

[maxkohl]

but registry entries DO left behind...the tweaks history remains there even after uninstalling, making next installation paint them blue (I already suggested before that the mechanism should get the current setting from the actual system state, that can reflect otherwise).

as for db files - I'm not sure I understood why then can disappear - they should reside in the AP folder. If someone uses something like re-packing, then the module aggregator (or whatever it is) should pick them up too - maybe designate them as "modules" (the db files) to work around this? am I talking sense here? I'm not sure that I really follow...if you mean that the user can simply get rid of the AP folder completely, then there's no issue - it's an "empty" case, hinting of a "lite" condition - no partial updating possible anyway over a non-existant folder...ok - clearly I'm missing something, so I'll wait for your comment here :)

about my other suggestion - I deliberately tried to avoid this term: "update system". I am aware that AP relies on mirrors for its distribution files, rendering a fixed update system difficult to maintain over time.

what I actually ment was more like a "manual" update system if it could be so described: the user should have had, per my suggestion, to d/l each and every component of the AP package seperately - the main disadvantage by this is losing AP's point of being a simple "package", but actually, if some of the work could become automatic, it'd be in regard of the raw hotfix files - if you ment that this was what been cosidered before, then I see.

the thought of leaving a stub behind, had occured to me because of AP's habit of leaving its registry entries behind anyway. I think that users will accept the extra 5.5MB lurking on their HD a little bit less reluctantly than they'd appreciate the entire, already-embedded, previous module files (maybe just clear the hotfix files? they'd never serve a partial update anyway...)

and about those start menu entries...<sigh> I've suggested numerous times about this, but nobody ever commented! this time I did a search and found my post, please see: https://www.neowin.net/forum/index.php?showtopic=420135

I wrote there exactly about aspects like this start menu items...of course they'd be welcome, but please read it all if you missed that thread back then - it has many suggestions.

BTW - I blew the title there: "net release" should've read "next release", could that have caused people to overlook my post? :( I'd appreciate your comments please :)

[+theblazingangel MVC]

i think maybe i wasnt very clear about the reg entries and db files.

if someone were to copy an autopatcher installation to another computer, registry entries would not be copied across, and so if another release was then used on that system, it would not be able to detect the current copy.

and as for a db file, we could use it to keep track of what autopatcher installations exist in the c:\program files\autopatcher directory, and new releases could check the file and warn the user if necessary, however what if someone deleted the file and so lost it, if something happened to files located in the directory and so the db was no longer a good reflection of what the directory contained, or what if someone copied and pasted another release on top and overwrote the db file?

a manual update system not have the disadvantage of bandwidth usage like an automatic system, however it sounds much more complicated for users.

i will have to think a bit more about an option to leave a 'stub' behind.

:D i didnt mean to make it sound like i was taking credit for the idea, i knew someone had asked before, and i had just remembered and though about actually doing it. your post offers a lot of ideas for the menu i hadn't thought of, i'll certainly look into doing it ;)

i think i will also perhaps look into creating a page offering the desktop icon, rather than forcing it, as you suggest, (leaving out the uninstall one), and an option to start autopatcher.exe.

oh, and dont worry, i never skip posts. i may not always reply and may forget to go back to some to do so or forget to write ideas down, but i always read them all ;)

Edited February 18, 2006 by TheBlazingAngel

[maxkohl]

I see your point with the registry. The files issue seems less likely to happen though (why would anyone mess with the internals of the folder?) but I think that my idea in the 1st reply here can answer that:

Assign each module an unique string/number, and you'll be able to identify it later - it means you'll embed this identifier in the module itself, and build a "module list" dynamically upon each new installation attempt of an update, to know exactly the state of the current AP folder that's already installed.

[+theblazingangel MVC]

sorry i havent replied in a few days, ive been working hard on the script (not quite finished yet).

the script is now about 7x the size it was before :whistle: . luckily its still very easy to customize :D :cool: and i think its worth it.

heres some screenies:

1) branding text, thanks to gandolas

2) optional page for update releases. if the user selects the 'lite' option, files specified in the script will not be extracted.

3) warning displayed when using an update release, and no previous release (autopatcher.exe) is detected.

note, i allowed a continue:yes option specially for you maxkohl ;)

also note, i am looking into changing the button text, so i can remove the odd looking "continue?" text. :x

4) warning displayed when using a full/lite release, and a previous release (autopatcher.exe) is detected.

continue:yes option available incase your instlling over a release of a different OS or language to combine them.

5) customised finish page. no need to explain it, you can see for yourself in the image.

----------------

In responce to the thread...

Actually im not so worried by people messing with the folders, but the db file being overwritten.

Before we started making the releases AIO compliant (comptable with each other), ive been using c:\program files\autopatcher 2k and autopatcher 2k3 as the install directories for those releases. (will change this asap, but cant do it yet while making just update releases..). If someone copied over the extracted releases into one folder to combine them, the database files would be overwritten, and so if a new release looked at it, it would seem there is only one release present rather than three! Even if i hadn't used different directories, other people could have done it themselves anyway by changing the install directories!

I have one solution to the problem, and thats to use plain text files with unique names (reflecting the filename of the installer). This would solve the overwrite problem, however it would be really really difficult to code...

The idea of assigning unique identifiers to modules and dynamically building lists is also an extremely difficult thing to code, and definately not practicle right now as far as i can see.

I've decided not to add a 'leave stub' option to the uninstaller, because its just going to make the script even larger and more complex, and i believe may confuse the average user, or encourage use of using update releases as standalones.

I've updated the faq to hopefully better inform users about using them for such a purpose, ive updated the ap-standalone download found in the standalone modules thread, and i will keep that up to date for you (nudge me if i forget), and where i can i will include extra (small) files to update releases to complete some included modules.

Any comments / other ideas anyone?

[maxkohl]

No problem with the delay, the result looks promising! :yes: I hope that with time, my other suggestions will be implemented too ;)

2) can't it be automatic? :rolleyes: If it helps, I can think of two ways to know that:

i) have the script search for a full-only module, OR, if you don't want to rely on that:

ii) have both full/lite installers to create a file, e.g. "release.ini" that has a "[type]" section, saying whether it's full or lite. Each installer will overwrite this file - as it should.

3) Thanks :D but I wonder how it could be of use actually...I thought of it more in the concept of a missing module - not an entire patcher basis ;)

If it really has almost no use for the normal user, maybe ditch the might-be-confusing dialog box (make it a one-way-out (quit) message box) and supply a command-line switch, say "/force", to allow such installation for the advanced user).

4) Cool! I wasn't sure if it was ever possible actually, so you say future patchers could be combined that way "out-of-the-box" ? BTW, You must do something about XP's AutoPatcher.exe refusing to run under Win2k environment, lest such combines will be useless :cool:

5) Great work, really, I appreciate it - as I'm sure many users will, too :)

----------

About the multiple-installations db file problem: Could this be solved by "appending" to it instead of just overwriting this db file?

Of course, if it'll be implemented, it has to be a "smart append" - some modules are common.

Thank you.

[gandolas]

^^ Very, very good work Blaze! I'm really impressed! Very good work! :D (Y)

[+theblazingangel MVC]

thanks (Y)

ive now finalised the script (v3.4). a summary of changes here (post#106)

ap_packing.zip v2.0 contains the new script, along with 'update.ini' and 'DumpLog.nsh' files which are used by it.

ap_packing.rtf (documentation) has been updated to v2.0

----------------

2) well, yes, it could, but, again im worried about people overwriting the file. it *should* be more reliable if the user decides.

3) well,

- it warns users that your not supposed to install update release to empty folders, but on top of the previous release.

- it allows you to actually install it to an empty folder if you really wish, but beware you may experience issues. note, if your installing on top of the standalone, you wont even see it anyway.

- i need it when analysing gandolas's update releases to create a changelog. i could just use the extraction log, but thats much harder to work with.

4) yep, you can install releases directly on top of each other.

if absolutely everyone did this when combining releases, then i wouldnt have to worry about db/ini files being overwritten because the installer could edit/append-to them. but i expect many people may extract to seperate folders and then copy and paste on top which would overwrite the file, which is whats causing my concern.

dont worry about ap v5.1.0.36, all releases are using v5.1.0.35 again until raptor fixes it (i imagine hes really busy, because he didnt respond to my email about it till 22 days later, and that was 16 days ago, but it doesnt matter v35 works fine).

5) (Y)

[perspectivism]

Hi Blaze.

I don't understand how I make to create an update release with standalone modules.... I've read the guide for packing (ap_packing.rtf ), but for me is difficult...

can you explain me clearly?

I've a confusion of folders....

Edited February 27, 2006 by Massimiliano2

[+theblazingangel MVC]

@Massimiliano2

err, the guide isnt meant for packing standalone modules. its actually meant for packing the main full/lite/update releases.

what exactly are you trying to do?

if you tying to add standalone modules to a packed release

- extract the release

- extract the standalone modules inside

- extract packing files into the folder beside autopatcher.exe

- follow the packing guide depending on what the original release your adding too was

if you trying to create a release containing just standalone modules, follow the above, except

- do not use an update release as the base

- delete all other modules from the modules folder