> On Nov 11, 2015, at 6:24 AM, Mateusz Viste <[email protected]> wrote: > > On 11/11/2015 12:00, Jerome E. Shidel Jr. wrote: >> Unzip seems to work fine for the packages on the FreeDOS 1.1 CD. (excluding >> JEMMEX, which has some >> attribute issues) >> I’m not sure what you mean by “too many details” ? > > Are you able to uninstall cleanly a package that you simply unzip? > (installation should not be a one-way operation). > > Is it possible to update a package with a newer version, once it has > been installed by FDI?
Good questions. I may be wrong, but it appears that the original FreeDOS 1.1 packages include “deployed” versions of the packages that include all the data to do what your asking. So, if 1.2 uses the same concept for it’s packages they should be able to do the same thing even if it just uses a basic unzip to perform the install. > > When installing non-core packages, do they land in some user-approved > location, or is everything going to %DOSDIR% ? The latter case would be > sad. And it might lead to file collisions, that need to be detected > BEFORE a package started to be unziped in any case. At present and always in basic (non-advanced) mode that would be the case. > > All the above are things that FDNPKG / FDINST take special care of. I thought those are 32-bit+ only? If so, they cannot be used by FDI to do the install. However, if all relevant data is included when packages are installed, the could be used later on to update/remove individual packages. > >> xcopy is needed to create a backup of the previous version of the OS. A >> simple move won’t work >> if the user wants to also keep the old files and just replace old files with >> new. > > That's what I was suspecting. But doesn't "replacing SOME files with new > ones, and keeping SOME old ones as-is" sound like a potential mess? I'm > not sure the user should have the possibility to keep anything he had > before (besides basic autoexec and config). Backuping of course is a > very nice and friendly thing to do. Agreed, thats why in normal/basic mode it doesn’t ask if the user wants to keep the old version or if they wish to back it up first. It assumes “yes” and will just do it. In advanced mode, it asks what the user wants to do about it. > >> deltree is needed to remove the old OS files if the user is not going to >> keep them. > > sounds very reasonable. > >> zip is needed for the alternate method of backing up the old OS files. (only >> in advanced mode) > > Okay, I was unaware of such possibility. Never seen such behaviour, but > if the user wishes it... why not. > >> fc is used for just a simple test at startup to see if the installer has >> already installed it’s version >> of the OS. If it detects that it’s version of the OS is already installed, >> it prints a message telling the >> user that they can run “SETUP.BAT” to manually start the installer and >> exits. That way, the install >> media can be used as a boot/recovery system without always being forced >> straight into the installer. > > Maybe then a 'boot / recovery system' could be proposed from screen one? > This is something most Linux distribution do. And it would make it > possible to avoid relying on trickery with FDI custom flag files. There is no reason the install media could not include some options like boot - recovery, boot - live cd… The testing implied by FDI to check it’s installed state is extremely rigid and mostly "born to fail”. When the test fails, the installer starts. More to less, it will only drop the user back to the prompt during initial boot when a default install has already been preformed. If the user, starts the installer manually, the test is NOT performed. The test only PASSES if the following conditions were met: Drive C exists and is Formatted, called from AUTOEXEC with RECOVERY option, release version identifier file is present in C:\FDOS and it matches that of the Installer. This is very similar to several major linux distributions and how they identify what “release” is installed. > > cheers, > Mateusz > > > ------------------------------------------------------------------------------ > _______________________________________________ > Freedos-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freedos-devel > ------------------------------------------------------------------------------ _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
