From owner-freebsd-questions@FreeBSD.ORG Tue Nov 29 15:21:28 2005 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CD4316A41F for ; Tue, 29 Nov 2005 15:21:28 +0000 (GMT) (envelope-from freebsd@redry.net) Received: from luke.segpub.com.au (luke.segpub.com.au [64.49.254.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id D65F743D55 for ; Tue, 29 Nov 2005 15:21:19 +0000 (GMT) (envelope-from freebsd@redry.net) Received: (qmail 20813 invoked by uid 89); 30 Nov 2005 02:21:18 +1100 Received: by simscan 1.1.0 ppid: 20774, pid: 20777, t: 1.9304s scanners: clamav: 0.87/m:34/d:1169 spam: 3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on luke.segpub.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from unknown (HELO ?137.43.83.191?) (137.43.83.191) by 0 with SMTP; 30 Nov 2005 02:21:16 +1100 Message-ID: <438C71EA.1080005@redry.net> Date: Tue, 29 Nov 2005 15:21:14 +0000 From: eoghan User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Lowell Gilbert References: <0EF126E2-9EC2-488C-A132-6D07A1761246@redry.net> <2C5E7622-7EC0-43D1-9DEF-4F87E2A90078@redry.net> <4464qdol6c.fsf@be-well.ilk.org> <44zmnokfrs.fsf@be-well.ilk.org> <438B31AA.5050709@redry.net> <44zmnoi4gx.fsf@be-well.ilk.org> <4464qbjy41.fsf@be-well.ilk.org> In-Reply-To: <4464qbjy41.fsf@be-well.ilk.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: krion@freebsd.org, freebsd-questions@freebsd.org, eik@freebsd.org Subject: Re: openoffice pkg X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2005 15:21:28 -0000 Lowell Gilbert wrote: > Lowell Gilbert writes: > >> eoghan writes: >> >>> Lowell Gilbert wrote: >>>> eoghan writes: >>>> >>>>> On 27 Nov 2005, at 21:06, Lowell Gilbert wrote: >>>>> >>>>>> eoghan writes: >>>>>> >>>>>>> On 25 Nov 2005, at 15:22, eoghan wrote: >>>>>>> >>>>>>>> Hello >>>>>>>> Im attempting to install the openoffice package and need to use a >>>>>>>> template cos it fills /var and then fails. I have used: >>>>>>>> pkg_add -r -t /max/tmp/instmp.XXXXXX openoffice >>>>>>>> but it still writes to /var? >>>>>>>> Anyone ideas what im doing wrong? >>>>>>>> Thanks >>>>>>>> Eoghan >>>>>>> Does anyone have any help on this? I assume im using the wrong >>>>>>> syntax? Does instmp.XXXXX need to exist in /max/tmp? >>>>>> No, you're right; it seems to be a problem. I haven't had a chance to >>>>>> look at it myself... >>>>> Thanks Lowell, do you mean it seems to be a bug? >>>> I haven't had a chance to look at it closely enough to tell. >>> Ok thanks, I will have a detailed look later on and see if I can >>> recover anymore information. >> I think it *is* a bug, but I haven't gotten a complete understanding of >> it yet. The pattern you pass in with the -t option seems to be getting >> dropped before you get to the utility function find_play_pen(), but so >> far I can't seem to figure out how it was supposed to be passed in the >> first place. As a workaround, the PKG_TMPDIR environment variable seems >> to work properly, and can serve your purpose just as well. > > On further analysis: > > The issue is specific to the combination of the -r and -t options. It > really get back to where the package file gets downloaded to, not the > work area that it expands to (which can't be set separately), so I'm > not really sure whether to consider it a bug or not. It certainly > would require changing some of the pkg_install library APIs to fully > separate the concepts. If you download the package by hand and use > the -t option, the temporary staging area will be used as you expect. Ok will get it manually and thanks for investigating this issue. I cant try it now, but if i get the pkg file manually and pkg_add it, will this have any effect on its dependencies? I mean will it still try "fetch" them remotely?