bugish: port not being rebuilt

[Ion-Mihai IOnut Tetcu]

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

>> I don't know how I ended-up with those ports having packages and
>> uninitialized DB entries, I didn't do it on propose, so it was
>> either the upgrade or the issues/debugging for the issues fixed in
>> the latest release.
>
> The only way I can see this happening is if a port entry is removed
> from the database, then later re-added.  The only code in TB which  
> removes port records implicitly is tbcleanup.

Might be. However since I see it on 2 Tindys (similar setup, true)
I'll try to investigate further. I play with the database, but not
with that table.

> Other than that, you would need to run "tc rmPort" manually.

That I don't think I ever used.


Thanks for your help,

-- 
IOnut - Un^d^dregistered ;) FreeBSD "user"
  "Intellectual Property" is   nowhere near as valuable   as "Intellect"
FreeBSD committer -> itetcu at FreeBSD.org, PGP Key ID 057E9F8B493A297B