Garrett D'Amore wrote: > Roland Mainz wrote: > > Joseph Kowalski wrote: > >> I'm sorry. I was supposed to contact you after the last PSARC meeting. > >> > >> There is no serious fast-track specification for this case. If we are > >> unable to proceed with out one. The project team needs to produce one. > >> > >> At a minimum, such a proposal needs a very clear list of the effected > >> utilities and the rationale for the list of effected utilities. > > > > Does that mean I have to make an ARC case for _each_ _single_ _binariy_ > > I make 64bit clean ? > > No. Two points: > > 1) Making a binary 64-bit "clean", but not delivering a 64-bit binary > (still just delivering the 32-bit binary) is just a bug fix, and well > below ARC radar. You can do that anytime you like, subject to CTeam.
Erm... I don't want to do the sisiphos work of doing the fixing and then have other people to undo them by accident. If I make the code 64bit clean I'd like to have a "safeguard" in place that noone can easily break it anymore... and the obvious "safeguard" is to just ship the 64bit binaries on platforms which only have a 64bit kernel anyway (which applies to SPARC([1]) and the Solaris port which shall-not-be-named). [1]=(SPARC is actually a good choice since it enforces the natural alignment of datatypes which is needed for some ports (but not all, e.g. AMD64 doesn't require this)) > 2) If you're going to deliver 64-bit binaries, you can provide a single > case listing multiple binaries. Technically - in the long term - this would include almost everything delievred by OS/Net+SFWNV. > If you're also removing (or converting) > a 32-bit binary, please make that explicit in the case. See above. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
