Subject: Re: SoC 2006: pkg_install rewrite?
To: None <tech-pkg@NetBSD.org>
From: None <email@example.com>
Date: 04/22/2006 20:42:03
On Sat, Apr 22, 2006 at 08:23:15PM +0200, Dieter Baron wrote:
> In article <firstname.lastname@example.org> 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):
> 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.
P.S.: Did I say I'm thinking about applying for this task?