Re: SRPM tries to build the RPM?

[Phil Muldoon <pmuldoon@redhat.com>]

> 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.