Hi Jeremy, 

Thanks for the response.  

You are correct to point out that I had the wrong path for mk.conf when
UNPRIVILEGED.  I realised later that I should have put etc/mk.conf
(without the leading slash).  Also I *did* spell UNPRIVILEGED correctly
in the Title!  I haven't tried to put that anywhere as yet either
because if I do know to put it in etc/mk.conf, then how do I tell the
pkgtools where to find it?  Do I do this with one of the bootstrap
options?  There is even less on UNPRIV instructions than on general
Linux bootstrapping---I have two problems: Linux and UNPRIV!  

I did come across a couple of bits and pieces for Linux and UNPRIV,
apart from that on or via pkgsrc.org.  For instance:
http://web.nmsu.edu/~brook/pkgsrc/ on UNPRIV.  I wonder how current it
is however; it seemed a little dated to me?...  I just found this too:
http://linux.pugetsoundtechnology.com/faq/ via
http://julipedia.blogspot.com/2005_04_01_julipedia_archive.html.  But
there's nothing I found on both...  

As for the multitude of platforms, is there any reason why pkgsrc
bootstrap can't (rather than keeping a database as does config.guess for
instance) detect lacks and report them all, at least.  At the moment it
reports the one it fails on and slows the whole process down thereby. 
Better still would be if it found lacks and installed them and kept
going if possible.  (I wrote some shell scripty stuff to determine if a
script was lacking and to retrieve it and keep running!  I had Java
Applet envy!  Perhaps something similar?)  A little bit like a fresh OS
install can choose to stay in text mode for longer or shorter (for geek
or non-geek respectively usually), perhaps pkgsrc could have a
pre-bootstrap bootstrap which resolves its own dependencies first?  And
are there RELEASE/STABLE versions and EXPERIMENTAL/UNSTABLE versions?  

As for MacOSX, I thought that it explicitly would not run: 

shiny:/pkgsrc/bootstrap root# ./bootstrap
===> bootstrap command: ./bootstrap 
===> bootstrap started: Sat Nov 12 10:47:57 EST 2005
Working directory is: work
===> running: /usr/bin/sed -e 's|@DEFAULT_INSTALL_MODE@|'0755'|'
files/install-sh.in > work/install-sh
===> running: /bin/chmod +x work/install-sh
===> Testing file system case sensitivity
===> running: /bin/sh work/install-sh -d -o root -g wheel
/usr/pkg/pkgsrc-REQUIRES-case-SENSITIVE-filesystem
"/usr/pkg" needs to be on a case-sensitive filesystem (see
README.Darwin)
shiny:/pkgsrc/bootstrap root# 

I should at least have the option to have a go, shouldn't I?  Can I
override this?  

As for RHEL3, how do you wish for me to send you a password for the
RHEL3 server?  (Obviously I won't send that to the list!)  I will also
do the bug report unless you'd rather, but it might be good for me to
know where to put it.  


t

On Fri, 11 Nov 2005 10:12:49 -0800 (PST), "Jeremy C. Reed"
<reed@reedmedia.net> said:
> On Fri, 11 Nov 2005, thoran wrote:
> 
> > On this page, http://www.netbsd.org/Documentation/pkgsrc/faq.html, it
> > says for non-root installs to attach the value yes to the attribute
> > UNPRIVELEGED but fails to mention where that attribute resides.  Does it
> > go in /etc/mk.conf?
> 
> Yes, set it in your mk.conf (wherever it is for you).
> 
> The UNPRIVILEGED support is not complete as I think only a few developers 
> work on it. I have done some bulk builds and have fouond many minor
> issues 
> that stop it from working. Some I have fixed but it is quite time 
> consuming.
> 
> If you or anyone uses it, please do not file bug reports for every issue 
> found unless you have a ready-to-apply fix. But do file bug reports for 
> the software that you do need.
> 
> (Note that you spelled it wrong above, so if you used that it may explain 
> why it didn't work.)
> 
> > Is there any chance of pkgsrc being able to work on HFS+?  Is having it
> > not run to do with an actual problem with case insensitivity, or is it
> > precautionary?
> 
> It might work in most cases. Feel free to try and let us know.
> 
> > Wasn't I going to test a fix on RHEL3 for something or other to do with
> > OpenSSL screwing up?
> 
> Please file a bug report about this. Or if you can provide access to your
> RHEL3 box, I will spend a few minutes looking at this for you.
> 
>   Jeremy C. Reed
> 
>   	  	 	 BSD News, BSD tutorials, BSD links
>  	  	 	 http://www.bsdnewsletter.com/