Mail Archives: opendos/1997/03/11/20:12:31
On Tue, 11 Mar 1997 jdashiel AT eagle1 DOT eaglenet DOT com wrote:
> The shared libraries problem is a rather trivial relational data base
> problem.
> two data bases would reside in /usr/apps,
> libsdat and apps.dat.
> The field structure for libs.dat is sequential and contains:
> record number (key),
> directory path,
> library name,
> apps count.
>
> apps.dat contains:
> app name,
> variable number of fields containing lib names record numbers.
>
> When an application is installed, a check is done for what shared libs it
> uses.
> If any shared libs are used, the app count field is incremented by 1.
> The application name is stored along with each of the record numbers for
> each shared lib.
> If more than 1 shared lib is used by an application,
> each associated app count is incremented by 1.
>
> When an uninstall happens,
> each associated app count number is decremented by 1.
> Only when a shared lib has an app count of zero can it be removed from
> the disk safely. If a shared lib is needed and not on the disk,
> installation
> programs will have to prompt the user for the system disk that has the
> lib on it and copy that lib into the directory.
> awk or perl could probably handle a data base application like this one.
> My normal method is to use dBase for them, but that's how I earned my
> money for the navy the past few years.
This sounds good, but a stand-alone program that can update these files
would help. Something that would look for programs that were deleted but
not removed from the database, and delete their entries. Mabey it could
even act as a universal uninstaller. There'll still be allot of people
who use del *.* to remove programs, and most DOS programs don't have
uninstall routines.
- Raw text -