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.

: If so, it'd be nice if we'd describe the project properly so that
: people looking at it could know what's really required.

: If you like the idea, here are some items to discuss.  We can later list the
: decisions in the project proposal:

: - Required functionality?

: It's obvious that the new pkg_install has to cover all areas that
: the current one handles (modulo deprecated stuff, if any; pkgviews?).

  Feature-wise, it has to be compatible.

  However, I would like to use this opportunity to improve some of the
internals:

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

  . It does not record mode and ownership of files.

  . It does not record directories.

  . It contains commands to execute on install/deinstall.  These
    should be part of INSTALL scripts.

  . It does not handle shared directories well (directories used by
    multiple packages that without a dependency relationship).

  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.

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

:   In order to get the above to work well while building from sources, one
:   might need some form of sandbox... in which case pkg_comp could be
:   deprecated by these new tools ;)

  We lack this ability badly, and we should design our tools to easily
allow that (i. e. include the building blocks needed).  However, if
it makes the project too big for SoC, we can add this later.

  [The code to create a pkg-summary file of a binary package
collection I'm currently working on forms an important building block
for this.]

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

:   The functionality we choose conditions what I list below.

: - Layered design?

:   Do we want to have a generic library to manage pkgsrc and binary
:   packages?  I think this could be an excellent thing to have because it'd
:   ease writing graphical frontends for pkgsrc, sysinst integration...

  I think this is a must, and one of the features most missing
currently:

  . Since NetBSD has no modern X11 GUI toolkit in base and a GUI
    frontend in Xaw won't win us major points with desktop users, a
    GUI will most probably be a separate program living in pkgsrc,
    which uses the functionality of such a library.

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


: - Programming language?

[Advocacy for C++ deleted.]

  I think C is the only choice, for several reasons:

  . A working C compiler is available on almost all platforms.
    For other languages, we would have to provide a
    compiler/interpreter implementation and a way to bootstrap it,
    which is a major piece of work and maintenance.

  . C code can be integrated in most other languages, allowing
    language bindings of the library and use of most other libraries
    and toolkits out there.

  . Almost all of NetBSD base is in C, so developers are expected to
    be fluent in it.

					yours,
					dillo