Subject: SoC 2006: pkg_install rewrite?
To: None <firstname.lastname@example.org>
From: Julio M. Merino Vidal <email@example.com>
Date: 04/15/2006 20:25:36
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=
nice if we'd describe the project properly so that people looking at it cou=
know what's really required.
If you like the idea, here are some items to discuss. We can later list th=
decisions in the project proposal:
- Required functionality?
It's obvious that the new pkg_install has to cover all areas that the cur=
one handles (modulo deprecated stuff, if any; pkgviews?).
But I'd add one (very important, in my opinion) feature to the mix:
to easily upgrade whole installations either from source, from binaries o=
both. This is difficult, but not impossible; other systems have got it. =
let's face it: upgrading the packages of a system (specially desktops) is=
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=
finished), I'd use C++. Managing data collections is trivial with the ST=
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=
and they literally boost the development of a C++ application. Furthermo=
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
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=
other languages -- the most obvious example being data collections or
child process management. No matter what, the results could be
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=
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 =
matters much, maybe, if the critical parts are written as auxiliary tools
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?
1: FreeBSD is also rewritting pkg_install. And they are splitting it in tw=
parts: a package-management library and the tools.
Julio M. Merino Vidal <firstname.lastname@example.org>
The Julipedia - http://julipedia.blogspot.com/