* SRPM tries to build the RPM? @ 2003-08-04 19:17 Austin Gonyou 2003-08-04 19:23 ` Tom Tromey 2003-08-04 19:23 ` Phil Muldoon 0 siblings, 2 replies; 6+ messages in thread From: Austin Gonyou @ 2003-08-04 19:17 UTC (permalink / raw) To: eclipse I tried to do an import of a SRC rpm and eclipse was actually building the RPM. Is that proper? It failed because of the syntax of my .spec file, but I wanted to import the src.rpm so I could manage all my src.rpms and specs under the same IDE as my perl, shell, and java code. -- Austin Gonyou <austin@coremetrics.com> Coremetrics, Inc. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SRPM tries to build the RPM? 2003-08-04 19:17 SRPM tries to build the RPM? Austin Gonyou @ 2003-08-04 19:23 ` Tom Tromey 2003-08-04 19:43 ` Austin Gonyou 2003-08-04 19:23 ` Phil Muldoon 1 sibling, 1 reply; 6+ messages in thread From: Tom Tromey @ 2003-08-04 19:23 UTC (permalink / raw) To: Austin Gonyou; +Cc: eclipse >>>>> "Austin" == Austin Gonyou <austin@coremetrics.com> writes: Austin> I tried to do an import of a SRC rpm and eclipse was actually Austin> building the RPM. Is that proper? It failed because of the Austin> syntax of my .spec file, but I wanted to import the src.rpm so Austin> I could manage all my src.rpms and specs under the same IDE as Austin> my perl, shell, and java code. I talked to Phil about this just the other day. And, btw, I don't think either of us thought of this particular failure mode. It turns out that we need to unpack the SRPM during the import process, to give you the ability to select what files are actually imported. We've talked about a few different ways to change SRPM importing to make this step unnecessary. One idea is to just always import everything. Another idea is to migrate the RPM plugin toward making it easier to do more RPM-editing steps, so for instance instead of choosing what files to import, you would choose what patches to apply. No real decision has been made yet. The RPM plugin is still in its early days. Input is definitely welcome. Tom ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SRPM tries to build the RPM? 2003-08-04 19:23 ` Tom Tromey @ 2003-08-04 19:43 ` Austin Gonyou 0 siblings, 0 replies; 6+ messages in thread From: Austin Gonyou @ 2003-08-04 19:43 UTC (permalink / raw) To: tromey; +Cc: eclipse On Mon, 2003-08-04 at 14:16, Tom Tromey wrote: > No real decision has been made yet. The RPM plugin is still in its > early days. Input is definitely welcome. Gotcha. This makes sense now. Guess I was expecting it to be like GVIM. ;) > Tom -- Austin Gonyou <austin@coremetrics.com> Coremetrics, Inc. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SRPM tries to build the RPM? 2003-08-04 19:17 SRPM tries to build the RPM? Austin Gonyou 2003-08-04 19:23 ` Tom Tromey @ 2003-08-04 19:23 ` Phil Muldoon 2003-08-04 19:41 ` Austin Gonyou 1 sibling, 1 reply; 6+ messages in thread From: Phil Muldoon @ 2003-08-04 19:23 UTC (permalink / raw) To: Austin Gonyou; +Cc: eclipse 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 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. regards phil On Mon, 2003-08-04 at 14:04, Austin Gonyou wrote: > I tried to do an import of a SRC rpm and eclipse was actually building > the RPM. Is that proper? It failed because of the syntax of my .spec > file, but I wanted to import the src.rpm so I could manage all my > src.rpms and specs under the same IDE as my perl, shell, and java code. -- Phil Muldoon <pmuldoon@redhat.com> Red Hat, Inc. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SRPM tries to build the RPM? 2003-08-04 19:23 ` Phil Muldoon @ 2003-08-04 19:41 ` Austin Gonyou 2003-08-04 20:06 ` Phil Muldoon 0 siblings, 1 reply; 6+ messages in thread From: Austin Gonyou @ 2003-08-04 19:41 UTC (permalink / raw) To: pmuldoon; +Cc: eclipse 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 -- Austin Gonyou <austin@coremetrics.com> Coremetrics, Inc. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SRPM tries to build the RPM? 2003-08-04 19:41 ` Austin Gonyou @ 2003-08-04 20:06 ` Phil Muldoon 0 siblings, 0 replies; 6+ messages in thread From: Phil Muldoon @ 2003-08-04 20:06 UTC (permalink / raw) To: Austin Gonyou; +Cc: eclipse > 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 <pmuldoon@redhat.com> Red Hat, Inc. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-08-04 20:06 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-08-04 19:17 SRPM tries to build the RPM? Austin Gonyou 2003-08-04 19:23 ` Tom Tromey 2003-08-04 19:43 ` Austin Gonyou 2003-08-04 19:23 ` Phil Muldoon 2003-08-04 19:41 ` Austin Gonyou 2003-08-04 20:06 ` Phil Muldoon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).