Hello,

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?  If so, it'd=
 be
nice if we'd describe the project properly so that people looking at it cou=
ld
know what's really required.

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

- Required functionality?

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

  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 o=
r
  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 ;)

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

- Programming language?

  If I had to do this myself (which I have even started in the past but nev=
er
  finished), I'd use C++.  Managing data collections is trivial with the ST=
L
  and one'd get a very nice object design to represent pkgsrc and packages.
  We'd also use some of the Boost libraries as their license is BSD-compati=
ble
  and they literally boost the development of a C++ application.  Furthermo=
re,
  one can easily copy the libraries he needs into the project by using 'bcp=
'
  (that is, no need to rely on the whole thing).

  The problem with C++ is that there might be issues to bootstrap the tool;
  a decent (standards-compliant) C++ compiler needs to be available,
  which is difficult to find.  Of course, if we provide prebuilt
toolchains, it's
  not a very big issue.

  Another possibility is to use C which IMHO would be rather silly.  Using
  C involves _too much_ work to deal with stuff that is given for granted i=
n
  other languages -- the most obvious example being data collections or
  child process management.  No matter what, the results could be
  interesting.

  We also have sh(1) as has been suggested some times.  I'm afraid of the
  results of such choice.  sh programs tend to grow uncontrollably and end
  up being unreadable.  The biggest problem with sh is to write something
  that works in different shells and with different tool sets!  sh is a lan=
guage
  but it cannot do anything without cut, grep, etc.  And we already now
  how difficult is to stick to the minimum common option set.

  But sh can still be a good choice if we stick to the current feature set.
  I don't want to imagine writing a package updater in such language, not
  even having a package-management "library".  Or how to handle
  translations?  At last, these tools wouldn't be specially fast (not that =
it
  matters much, maybe, if the critical parts are written as auxiliary tools
  in C).

  And what else?  Perl, Python?  No, I do not think so; these are rather
  fat dependencies and despite they are included by default in many
  OSes, they are not and won't be in NetBSD.

  In case you haven't guessed already, my vote goes to C++ ;-)

Nothing more for now.  Comments?

Thanks!

1: FreeBSD is also rewritting pkg_install.  And they are splitting it in tw=
o
   parts: a package-management library and the tools.

--
Julio M. Merino Vidal <jmmv84@gmail.com>
The Julipedia - http://julipedia.blogspot.com/