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.

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

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

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

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