Re: pkgsrc tree on fat filesystem

[lausgans%gmail.com@localhost]

Greg Troxel <gdt%ir.bbn.com@localhost>:

> You may also want to work on cross compilation for pkgsrc.  There is
> some work needed in infrastructure, and then many packages will need
> help.  That might be easier than building native.  But it might not
> be :-)

This definitely shouldn’t be a one man project, and there should be an interest
from the community :)
Actually, everything just works (leave fat aside), but works slow (i should try
ccache). So another viable alternative would be building on few similar devices
with help of distcc.

Joerg Sonnenberger <joerg%britannica.bec.de@localhost>:

> On Mon, Oct 06, 2014 at 01:55:50PM +0400, lausgans%gmail.com@localhost wrote:
>> I’m interesting in whether the subject is possible?
>> I’ve heard that one may put pkgsrc on case-insensitive
>> fs, and that’s good, but how about fs without posix permissions?
> 
> The pkgsrc tree itself should not care, but the work area and the prefix
> do. If permissions do matter in some places for the main tree, it is a
> bug.
> 
> Joerg

I hope so. Actually i’m experiencing a trouble with relative paths:

Greg Troxel <gdt%ir.bbn.com@localhost>:

> I would suggest that you set PKG_DEBUG_LEVEL=1 in mk.conf, and then try
> to do various operations, like "make show-depends" and
> "make show-vars VARNAMES=PKGNAME».
> If that doesn't work, then other than debugging it yourself you could
> post the output (or put it up and send a link).  Make sure to include OS
> type and version, cpu, etc.

It always brakes the same not matter which operation i’m doing. Here’s the output:
http://pastebin.com/ZYsrvYsv It includes os, cpu, etc details as well.
PKG_DEBUG_LEVEL=1 doesn’t affect output at the wreck stage.

One question here. I’m currently going with qnx folks tree, like they recommend:
http://community.qnx.com/sf/wiki/do/viewPage/projects.pkgsrc/wiki/Bootstrap
(pkgsrc.org leads there too). Should i try latest stable stock pkgsrc tree instead?
I don’t know a reason why they keep that tree. Hadn’t they committed their patches
upstream? BTW, i haven’t noticed any special qnx workarounds for packages i’ve
tried.