I see the problem - when you move the %DOSDIR% directory away (or backup it), you loose all meta information about potentially installed packages.
In fact I wonder if there is a point in trying to solve such cases - after all, if the user has some packages installed, then he doesn't need the install CD (because he could update his system via fdnpkg just as easily)... Maybe should there be two methods that FDI could use, depending on what is currently installed? 1. If system is not supporting packages -> just backup all, create a new DOSDIR and install base 2. If system seem to have support for packages -> do not touch %DOSDIR (maybe just backup a copy it into a zip or so), and instead do a remove/install loop on all BASE packages from the CD? Mateusz On 11/11/2015 20:36, Jerome E. Shidel Jr. wrote: > >> On Nov 11, 2015, at 2:18 PM, Mateusz Viste <mate...@viste.fr> wrote: >> >> On 11/11/2015 20:09, Jerome E. Shidel Jr. wrote: >>>> What do you mean by "time consuming" ? FDINST REMOVE won't do anything >>>> if the package is not installed - it will execute only a check >>>> determining whether or not said package is already installed. This is >>>> something that needs to be done anyway. >>> >>> Mostly, I mean going through all of the lists in batch logic. >> >> No need to do any batch logic - when installing a package, simply call: >> >> FDINST REMOVE %PKGNAME% >> FDINST INSTALL %PKGNAME%.ZIP > > Unfortunately, that won’t work. It will require the batch logic. > If the user is running in normal mode, (backup & purge my %DOSDIR%) when > it gets to the part it will install the packages, they report “Not installed” > even > if they are installed. This is because all package information has been > purged. > So, all conflicting packages must be uninstalled prior to purging the > %DOSDIR% or > they will fail to install due to conflicts. > >> >>> Without going through a package list comparison and removal. Simply, >>> removing >>> all installed packages would dump files the user may have installed to a >>> different >>> directory that are not included in the FreeDOS release. The user would see >>> it as >>> having trashed there install of blahblah package installed in C:\MYTHING\. >> >> This is the bit I don't understand. If the user copied some files around >> (as opposed to having them "installed" using FDNPKG or FDINST), then the >> REMOVE action won't touch them, because FDINST will simply be unaware it >> their existence. >> >> If you are worried about packages that user installed, but that are not >> present in the FreeDOS v1.2 distro, then worry not - these will be left >> unharmed. FDI shouldn't try to remove "every possible package installed >> in the system" - only the packages that it wants to install (ie. only >> BASE, or whatever else is being installed). > > If FDI uninstalls every package that is currently installed, but doesn’t > include any custom packages, then it will probably be removing things the user > does not want touched outside of the %DOSDIR%. > >> >>> An install or upgrade if installed option would be nice. It isn’t a >>> conflict if it is >>> upgrading a earlier version. :) >> >> I agree. And that's why I keep suggesting using a combo REMOVE+INSTALL >> for every package that the distro is trying to install. If a package >> doesn't exist, it will be installed. If a package was existing, it will >> be upgraded. Any other pre-existing package will be left untouched. > > But, it won’t upgrade a pre-existing file. So, if someone were to download > version 1.0 of BLAH from sourceforge and drop it in they’re C:\games > directory. > If FDINST tries to install version 2.0 of a blah.zip package, it will fail. > Since it has > no package information about blah.zip, it will also fail to remove it the old > version. > A user is forced to hunt down every file associated with BLAH, then to install > the new version. > > >> >> Mateusz ------------------------------------------------------------------------------ _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
