Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 13 Apr 2010 14:05:51 +0400
From:      Alexander Churanov <alexanderchuranov@gmail.com>
To:        Robert Watson <rwatson@freebsd.org>
Cc:        freebsd-hackers <freebsd-hackers@freebsd.org>, Leinier Cruz Salfran <salfrancl.listas@gmail.com>
Subject:   Re: make pkg_install suite reusable, please
Message-ID:  <o2v3cb459ed1004130305n70aaf11ez2fb97a7f75d4a0cc@mail.gmail.com>
In-Reply-To: <alpine.BSF.2.00.1004111235330.80625@fledge.watson.org>
References:  <x2ta2585ef1004090716vf74893dfo9d5412455294c64d@mail.gmail.com> <q2x3cb459ed1004090736t5a67f315geca1c199a5061e7d@mail.gmail.com> <alpine.BSF.2.00.1004111235330.80625@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
2010/4/11 Robert Watson <rwatson@freebsd.org>

> So I have no particular opinion on this tool, but I will say that in
> general, it would be nice if programs were often thin wrappers around a
> library that could be reused, not just command line tools.
>
> Robert
>

Robert,

The reusable library is great. The question is how it works with the
underlying system. When dealing with a package database, one may provide a
library which directly reads and writes the database. On the other hand, the
library may re-use some command-line tools. In the latter case there are
chances for the package manipulating tool to stay consistent even if the
memory in the calling process (which uses the library) is damaged. The
database files are also less likely to became corrupted. Of course, run-time
performance should be sacrificed.

To summarize, there are two ways:

1) Provide the re-library and make command-line tools be just wrappers
around the library.
2) Provide command-line tools and make the library to be just a wrapper
around the tools.

Approaches provide different trade-offs between run-time performance and
isolation.

Alexander Churanov



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?o2v3cb459ed1004130305n70aaf11ez2fb97a7f75d4a0cc>