>   I have to admit I am leaning towards possibly re-implementing
>   pkgmanager in some other language, mostly due to get support for
>   threads, better portability and better POSIX integration.
>
> The pkg_rolling-replace code is in /bin/sh and awk.

Ok. Going that far is not suitable for me because I want pkgmanager to do a 
lot of things that isn't easily implemented in a sane way with shell scripts. 
But with the base system requirement, C remains an option. Will give it some 
thought, although I don't personally have any problem with a tool depending 
on packages that are (after all) available in pkgsrc.

> Ruby isn't part of the base system, so there's an issue there.  If
> there's a small package that runs ruby, and it doesn't have 5 versions
> like python, and isn't constantly changing, then it might be ok for some.

I have never run into version hell with Ruby so far (other than "requires 
version 1.8 or newer"), though I magine Ruby 2.0 will create some 
incompatibilities.

>   If C is an absolute requirement for a tool to be generally accepted
>   - would the use of boehm-gc kill off that advantage? Opinions?
>
> boehm-gc means going beyond the base system, but if there's a binary
> (esp if static) that can then be used, that's not so bad.  For
> programs like we're talking about, the operations in question don't
> really seem that hard that features like garbage collection seem
> necessary.

It's mostly personal preference. I don't like having to spend time working 
around the limitations of the language, even if the problem is not 
significant enough that it poses a real problem.

> I should point out that another difference with the rolling-replace
> approach is that the pkgsrc code itself is modified to have make
> replace do the unsafe marking, so that the metadata is accurate
> always, rather than only when using a tool.  But, pkgmanager could
> certainly use the same tags - that's an orthogonal issue.

pkgmanager currently does not maintain any kind of internal state between 
runs, and is only dependent on the state of the system (and I very much agree 
this is a desired feature, there is nothing worse than some package manager 
getting permanently confused and disabling the whole system).

Well, interesting feedback - thanks! I will give it some more thought, but I 
am scepticle to the basesystem-only requirement.

-- 
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey@scode.org
E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org