Re: [WBEL-devel] Missing libpng and libpng10 updates

[email protected] (Paul Iadonisi) writes:

> On Wed, 2004-05-26 at 15:41, Jesse wrote:
> 
> [snip]
> 
> > I don't know if John does extra steps, but you can roll your own for most
> > packages pretty easily.
> > 
> > Download the SRPM.
> > rpm -ivh the SRPM
> > cd /usr/src/redhat/SPECS
> > rpmbuild -bb theprogram.spec
> > When it's done compiling, you should see a binary RPM in one of the
> > subdirectories of /usr/src/redhat/RPMS
> 
>   No!  Don't do that!  ;-)
> 
>   It's actually not a big deal if you do, but you've got an entirely
> unnecessary step in there.  You simple need to do a 'rpmbuild --rebuild
> <SRPM>'.  No need to install it first and then build from the spec
> file.  Why bother doing that when it means you now don't know which SRPM
> to keep around for possible future purposes.  I'd only keep a
> (differently named by changing the Release: tag in the spec file) self
> generated SRPM around if I made changes to it, like John's trademark
> changes.
>   And frankly, if you're maintaining your own updates, the only custom
> ones you need are anaconda-images and redhat-logos.  John has taken the
> safer (but more involved) route of removing anything that could lead one
> to believe that WBEL comes from Red Hat.  Wise for WBEL, but not really
> necessary if you are maintaining your own binary RPMS built from SRPMS.

The issue of the updates is what probably causes the delays (the
process is manual).

Excluding the Whitebox modified rpms the ideal situation would be a
way to [A]:

1. detect new src rpms available on RedHat's ftp/web server
2. rebuild them
3. test the rpms [optional?]
4. make the rebuilt binary rpms available to the public
5. announce their availability

Whitebox modified rpms would require the same process that John is
currently doing [B].

I am currently working on a build procedure[*] which will allow me to
do both [A] and [B].  The process is not as straightforward as it
should be [even when hosted on WBL] due to the fact that many
dependencies are not actually in the spec files and I don't like
having to install ALL rpms just to get the builds to work.  There are
other issues too, apart from me working on this part time.

However if we could automate the rebuild at least of the updates then
the work involved by John (or whoever) would drop dramatically and
also the RPMs would be made available much more quickly.

Perhaps we can help John automate [A] leaving the problematic RPMs
aside for the moment then everyone will know that they can expect to
find updates binaries within a reasonably short time frame of the
source rpms being made available.

I would be happy to work with someone to get this working.

Regards,

Simon
[*] ask me off list for more details.