Gearing up for 64-bit time_t on sparc64

[Garance A Drosihn]

At 10:28 AM -0800 1/6/04, David O'Brien wrote:
>On Tue, Jan 06, 2004, Harti Brandt wrote:
>  > That's just what I did. The real problem is the upgrade
>  > procedure and whether we will force people to recompile
>  > everything (and not provide a compatibility library).
>
>I think we can have a 'Flag Day' and not deal with a compat lib.

That's what I was going to shoot for.  While I did not get a lot
of reaction to my previous messages in November, it seemed that
most people thought we should just make the change.

>  > The only problem with the upgrade procedure I had was with
>  > tic, that for some reason got into an endless loop when
>  > running on the wrong kernel.
>
>We would need a fool-proof procedure for going from say a
>5.0-R install to post 64-bit time_t.

How flexible should we be?  My first thought is to tell people:

    1) upgrade to RELENG_5_2
    2) *after* you know that upgrade worked, then run a patch
       file (which will already be in /usr/src?), which will
       modify the appropriate files needed for this change.
    3) rebuild after making just that one change.  No cvsup.
    3a) ...details to be filled in...
    3b) ...blah blah, rebuild key ports, etc etc...
    4) change your cvsup files to tag=.

Or we could do a more flexible version, combining a -Define in
CFLAGS (set in /etc/make.conf), along with some extra magic
when installing the include files during 'make installworld'.
Some flag such as -DSPARC_TIME_T=BIT32 vs =BIT64.

The remaining steps would be the same, but users could flip
the switch at whatever time they wanted, instead of being
forced to upgrade to RELENG_5_2.  I think users should still
do a "double install", where they first have to get thru a
successful install at one point, and then modify the setting
in /etc/make.conf and immediately do a second install.

I think it is a good idea to have everyone upgrade to RELENG_5_2
first anyway, because we already have quite a lot of changes
between 5.0-Release and RELENG_5_2.  However, I'd be willing to
work towards the second idea if other sparc users really want the
more flexible option.

I realize I skipped over the important details in "step 3", but
I hope to start filling those in later this week or the weekend.

-- 
Garance Alistair Drosehn            =   gad at gilead.netel.rpi.edu
Senior Systems Programmer           or  gad at freebsd.org
Rensselaer Polytechnic Institute    or  drosih at rpi.edu