In article <20060422193522.GA15336@britannica.bec.de> joerg@britannica.bec.de wrote:
: >   However, I would like pkg_install to be able to be able to do the
: > update if using only binary packages.  That feature is too important
: > (especially for casual/naive users) to require an external tool for
: > it.

: Two possibilities exist to handle it:
: (a) Allow full inplace updates, e.g. extract the package to temporary
: dictories on each affected filesystem and register the new meta status
: and rename them to the correct name. This works pretty well for minor
: updates as long as old version and new version are compatible.

  This can be checked via PROVIDES and REQUIRES, at least for shared
libraries (and is the reason these variables exist).

: (b) Allow "transaction"-like modifications of the system. E.g. remove
: all packages which can't be updated inplace and which have conflicts
: with the versions to install. Install the new versions afterwards.
: This is similiar to what "make update" and "pkg_chk" already do, but
: would be backed up by the system.

  This is what I had in mind, optionally creating binary packages of
the to-be-deleted packages, so a rollback can be done.


: >   What do you mean by analysing a binary package?  Extract build info
: > and the like?

: Extracting build infos, dependencies, file and directory lists etc. E.g.
: what (1) offers for an installed package. Thinking twice, it should be
: available as library as well.

  Okay, then we agree.

: >   I disagree about (4): We'll want a GUI to manage installed packages
: > eventually (not in pkg_install itself, but as a separate program), and
: > that program will need to install packages.

: Exactly. But calling an external program is good and necessary since it
: is a prequirement for proper priviledge separation. E.g. if we have a
: tool like dselect or aptitude or whatever, I definitely want to run it
: as non-root, but the actual installation has to be done as root of
: course.

  I see.  I never considered being able to run the GUI as non-root
when installing/deleting packages, but I see why one would want to.

: Don't get me wrong, a wrapper library to ease the use is perfectly fine
: and valid, but as primary interface, the command line is better IMO.

  You mean a library function interface that does the program
invocation, possibly with just-in-time-su?  Sounds reasonable.

						yours,
						dillo