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:
: > : It has been said multiple times that pkg_install has to be rewritten from
: > : scratch because the current code is very difficult to modify(1).  SoC 2006
: > : may be a good opportunity for this to happen; don't you think?
: > 
: >   I'm not entirely convinced a complete rewrite is necessary.  Several
: > improvements have been made to pkg_install, restructuring and
: > improving the code they touched.  I think a cleanup and refactoring of
: > the existing code would be less work than a complete rewrite.  But
: > either way, it would be a good SoC project.

: I disagree. The current code base is lacking in quite a lot areas and
: even to clean those up is a lot of work.

  Okay, I guess it's the implementor's call.

: >   Feature-wise, it has to be compatible.

: I'd say it has to offer a superset of the currently used functionality.
: The infamous extended subset :-)

: >   The PLIST file format has some annoying deficiencies (Thomas and I
: > wrote a mail about that a while back):

: [snap]
: Agreed.

: >   The standard INSTALL fragments (handling rc.d scripts, users/groups,
: > info files) should not be duplicated in each package, but should be
: > part of pkg_install.

: Agreed as well.

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

: > :   At last, do we want localized messages, etc?

: I'm not sure if I want to have them in the "backend". I certainly don't
: want a gettext dependency of the package tools.

  Sounds reasonable.

: > :   Do we want to have a generic library to manage pkgsrc and binary
: > :   packages?
: > 
: >   . Bindings for the library in other languages (like Perl) can be
: >     created, which allows for tools and prototypes to be written in
: >     them.  (p5-pkgsrc-Dewey is a first step in this direction, but
: >     wrapping a library would be much easier.)

: 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?

  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.  It can either do this by
calling functions in the library or by executing the pkg_install
programs.  I generally prefer function calls to executing external
programs, so I think it is useful and desirable.  Why do you think
otherwise?

: > : - Programming language?
: > 
: > [Advocacy for C++ deleted.]
: > 
: >   I think C is the only choice, for several reasons:

: [Reasoning for C deleted.]

: I also agree that C is the only real option.

: Joerg

: P.S.: Did I say I'm thinking about applying for this task?

  Sounds great.  I'm thinking about mentoring it.

					yours,
					dillo