Subject: Re: SoC 2006: pkg_install rewrite?
To: None <tech-pkg@NetBSD.org>
From: Dieter Baron <firstname.lastname@example.org>
Date: 04/22/2006 21:20:38
In article <20060422184203.GA7959@britannica.bec.de> email@example.com wrote:
: 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.
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):
: > 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
: > : 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.
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
: > : - 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?
Sounds great. I'm thinking about mentoring it.