[sbopkg-users] abiword & Update Function

[Chess Griffin]

* Robby Workman <rw at rlworkman.net> [2010-06-17 14:00:34]:

> On Thu, 17 Jun 2010 14:08:13 -0400
> Chess Griffin <chess at chessgriffin.com> wrote:
> 
> > * Marc Payne <marc321 at gmail.com> [2010-06-17 11:01:10]:
> > 
> > > I ran some updates this morning and experienced the same issue that
> > > alkos333 described, using sbopkg 0.33.1. Several packages were
> > > flagged with x.y.z-noarch (graveman and yasm are a couple
> > > examples). After building, the packages had the correct arch of
> > > i486, so it seems there may still be a cosmetic bug lurking in the
> > > shadows.
> > > 
> > 
> > Yes, this is a cosmetic issue -- the resulting packages will have the
> > ccrrect ARCH.
> > 
> > The line 707 fix is not the complete answer but we're working on it.
> > Thanks for the reports, everyone.
> > 
> 
> 
> Maybe I'm overlooking something, but aside from having an
> UNSUPPORTED value of DOWNLOAD_x86_64 or MD5SUM_x86_64 in the
> .info file for the app, I don't see why you wouldn't just
> return the ARCH of the running system.
> 

Yes, we had considered that but it would provide incorrect information
in the case of SlackBuild scripts with hardcoded ARCH information, or
'noarch' and the like.  So we've tried to be fancy by eval'ing the ARCH
in the SlackBuild script to provide a more accurate output.

We might end up just using the system's ARCH, or inserting a
'placeholder' like 'ARCH', or just removing the ARCH from the string of
installed and updated packages since it really is not that relevant to
the actual determination of whether an APP is at $VERSION or $VERSION+1.

-- 
Chess Griffin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://sbopkg.org/pipermail/sbopkg-users/attachments/20100617/b46732ae/attachment.sig>