From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24936 invoked by alias); 4 Aug 2003 20:06:44 -0000 Mailing-List: contact eclipse-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: eclipse-owner@sources.redhat.com Received: (qmail 24926 invoked from network); 4 Aug 2003 20:06:43 -0000 Subject: Re: SRPM tries to build the RPM? From: Phil Muldoon Reply-To: pmuldoon@redhat.com To: Austin Gonyou Cc: eclipse@sources.redhat.com In-Reply-To: <1060025357.3009.51.camel@portageek.digitalroadkill.net> References: <1060023892.2358.39.camel@portageek.digitalroadkill.net> <1060024987.1155.5.camel@dhcp-50.hsv.redhat.com> <1060025357.3009.51.camel@portageek.digitalroadkill.net> Content-Type: text/plain Organization: Red Hat, Inc. Message-Id: <1060027600.3171.29.camel@dhcp-50.hsv.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: Mon, 04 Aug 2003 20:06:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2003-q3/txt/msg00029.txt.bz2 > It does all that, but it actually goes beyond that and did a full > build > of all the parts of my RPM. I'm sure it's just an RPM syntax problem, > i.e. it's installing stuff in /usr/local/bin(vs > %RPM_BUILD_ROOT/usr/local/bin). Some things I inherited and haven't > fully sorted through yet. I'm going to need a little more context. Bear with me :) It should be installing in /var/tmp/{uname}/ which is our buildroot with the name rpm name.temp. > or it just allowed one to build RPMs, after > modifying the specs, etc. You should be able to both build RPMS and SRPMs with the export functions. There should be two entries in the export section, Binary RPM and Source RPM. > I guess I was expecting it to unpack the > src.rpm and then just import all the files into the workspace, vs trying > to build anything at all. (i.e. I don't want patched versions, \ Yes, the srpm import was more designed to be cookie cutter. But this kind of input is very valuable. We could add two different check-boxes to the gui that allow something like, don't apply patches and don't build that would just preserve the raw sources; which should not be very hard at all, as they just provide two simpler use cases. Tom and I chatted about this very recently, such as applying patches conditionally through user input; resolving patch collisions and so on. The only problem would the applicability of other rpm functions from within Eclipse. Right now, if you import an SRPM, we allow you to re-export it as a Binary RPM and Source RPM using the same spec file you imported with. We would have to limit these functions if we allow the user to control the scope of the spec file that is to applied. Thanks for your suggestions and your input, they are very valuable. I'll discuss them with the other plug-in developer here, and see what comes about. I'll keep you informed. regards phil On Mon, 2003-08-04 at 14:29, Austin Gonyou wrote: > On Mon, 2003-08-04 at 14:23, Phil Muldoon wrote: > > Austin, > > > > It has to install the SRPM in a temporary environment to apply patches, > > and so on so that it can give an accurate representation of the files in > > the SRPM carries. Is this what you mean? > > It does all that, but it actually goes beyond that and did a full build > of all the parts of my RPM. I'm sure it's just an RPM syntax problem, > i.e. it's installing stuff in /usr/local/bin(vs > %RPM_BUILD_ROOT/usr/local/bin). Some things I inherited and haven't > fully sorted through yet. > > It would be nice if it had spec file syntax highlighting though, which > is kind of what I expected, or it just allowed one to build RPMs, after > modifying the specs, etc. I guess I was expecting it to unpack the > src.rpm and then just import all the files into the workspace, vs trying > to build anything at all. (i.e. I don't want patched versions, I want > the proper versions as they look from the SRC as I were to do rpm -ivh > some.src.rpm) so that actual modification makes more sense, regarding > the sources. > > > It also invokes make on the code when you have selected the files and > > begin the import. This is is because Eclipse sees that is has a C nature > > and tries too build it. If you would like to post the logfile it > > produces (it would give you the name in the error dialog) we can take a > > look and see what is happening. > > Yeah, I was wondering why RPMBUILD was being called. I was only > expecting what I noted above. > > > regards > > > > phil -- Phil Muldoon Red Hat, Inc.