bugish: port not being rebuilt

[Joe Marcus Clarke]

On Thu, 2008-11-27 at 10:06 +0200, Ion-Mihai IOnut Tetcu wrote:
> [ writting from webmail, sorry for the bad formatting ]
> 
> On Thu, November 27, 2008 08:29, Joe Marcus Clarke wrote:
> > On Thu, 2008-11-27 at 07:52 +0200, Ion-Mihai Tetcu wrote:
> >> On Wed, 26 Nov 2008 20:41:10 -0500
> >> Joe Marcus Clarke <marcus at marcuscom.com> wrote:
> >>
> >> > On Wed, 2008-11-26 at 23:39 +0200, Ion-Mihai Tetcu wrote:
> >> > > Hi,
> >> > >
> >> > >
> >> > > If a package for the current PKGNAME exists but the entry in the
> >> > > database is "uninitialized", the port won't be rebuilt by
> >> > > tinderd
> >> > > and no error will be shown anywhere.
> >> > > This happens both with 2.x and latest 3.x releases; with
> >> > > tinderd_flags="--nullfs" (and irrespective of tinderd_flags
> >> > > containing "-plistcheck -onceonly" or not).
> >> > > The same is true if the port is build via tinderbuild.
> >> >
> >> > How can you reproduce this using tinderbuild alone?  The way
> >> > tinderbuild should work by default is to rebuild all ports
> >> > explicitly spelled out on the command line.
> >>
> >> Well, yes, sorry if I wasn't clear above/bellow. Here it is:
> 
>  [ .. ]
> 
> >> I reproduced it on two separate boxes, one running latest 2.4 and
> >> the other running latest 3.1, so you shouldn't have any problem
> >> reproducing it also, but I can give you console access if you want.
> >
> > Okay, this makes sense.  The code uses the last_built_version data
> > from the database to determine what package files to delete when -
> > norebuild is not specified.  The fact that this column is NULL
> > explains why this happens.
> 
> OK, this I can fix. I have a postBuildHook that schedules the next
> port in the category or the first one in the next category. So I'll
> add a check to see if there's a current package for that port and rm
> it.
> 
>  [ .. ]
> 
> >> > > I have a feeling this situation (existent up-to-date package,
> >> > > uninitialized entry in the DB) can happen after an Tindy
> >> upgrade.
> >> >
> >> > No, this shouldn't be the case.  An upgrade will not reset port
> >> > build
> >> > entries in the DB.
> >>
> >> Well, no, an update leaves you enough times w/o any entry in the
> >> tables. BTW, for the next updates I'll work on a "ALTER TABLE ..."
> >> instead of current "DROP TABLE / CREATE TABLE" upgrade for mysql
> >> since I  can't afford to lose QAT tables data.
> >
> > The 2.x to 3.0 upgrade was a special case.  Even in that case,
> > virtually all table data was preserved.  However, all other upgrades
> > (e.g. from 3.0.2 to 3.1) used ALTER TABLE syntax.
> 
> Speaking of which, I really think it would be nice to have the
> compleate DS version in the database (major.minor.micro); think of the
> port users that, for one reason or an other can't update immediatelly
> after a release is out and they end up doing the update from 3
> releases behind.

The major.minor.micro dsversion is stored in the database.  The micro
version is only used when static data changes occur.  The upgrade
framework has always supported upgrading from a release a few revs back
with the notable exception of the 2.x to 3.0 jump.

Joe

-- 
PGP Key : http://www.marcuscom.com/pgp.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://marcuscom.com/pipermail/tinderbox-list/attachments/20081127/9c80c106/attachment.bin>