[WBEL-devel] Missing libpng and libpng10 updates

[Tim Fournet]

Perhaps this utility can be of help to help create distributed
repositories: 
http://dag.wieers.com/home-made/yam/

>From the description: 
Yam builds a local Apt/Yum RPM repository from local ISO files,
downloaded updates and extra packages from 3rd party repositories. It
takes care of downloading updates and extras, configuring HTTP access
and providing PXE/TFTP resources for remote installations.



On Thu, 2004-05-27 at 11:06, Simon Mudd wrote:
> pri.wbel1@iadonisi.to (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.
> _______________________________________________
> Whitebox-devel mailing list
> Whitebox-devel@beau.org
> http://beau.org/mailman/listinfo/whitebox-devel