On Sat, Apr 22, 2006 at 09:20:38PM +0200, Dieter Baron wrote:
> In article <20060422184203.GA7959@britannica.bec.de> joerg@britannica.bec.de wrote:
> : On Sat, Apr 22, 2006 at 08:23:15PM +0200, Dieter Baron wrote:
> : > In article <6b2d1e190604151125q2d930786gfd49add7b758e6f9@mail.gmail.com> Julio wrote:
> : > :   But I'd add one (very important, in my opinion) feature to the mix:
> : > : the ability
> : > :   to easily upgrade whole installations either from source, from binaries or
> : > :   both.  This is difficult, but not impossible; other systems have got it.  And
> : > :   let's face it: upgrading the packages of a system (specially desktops) is a
> : > :   royal PITA nowadays.
> 
> : The packaging tools have to provide the binary package part, how we deal
> : with building the package is a completely separate issue.
> 
>   I think we should provide a method to updates all installed
> packages, from binary if available, compiling in a sandbox if not.
> This does not have to be part of pkg_install itself, but might be
> provided by another tool.
> 
>   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.
(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.

The pkgview concept would allow to always use (a) to keep distinct
versions current without having to install too many versions.

> : The necessary functionality falls into the following categories:
> : (1) Requesting information about the installed system.
> : (2) Requesting information about a (remote) (binary) package repository.
> : (3) Analysing a given binary package.
> : (4) Installing, registering and building a binary package.
> 
> : I think for the first two items exporting the interface as library is a
> : must-have item. The third point is nice to have, but maybe not exactly
> : necessary. The last point is not useful as library, IMO.
> 
>   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.

>   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.

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.

Joerg