Running i386 binaries on amd64

[Kövesdán Gábor]

Julian H. Stacey wrote:
> =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= wrote:
>   
>> Julian H. Stacey wrote:
>>     
>>> gabor.kovesdan at t-hosting.hu wrote:
>>>   
>>>       
>>>> either, you have to get the RELENG_6_1 
>>>>     
>>>>         
>>> RELENG_6_1 is for stable beyond, which jim might not want,
>>> to match release if uname -r == 6.1-RELEASE : RELENG_6_1_0_RELEASE
>>>   
>>>       
>> RELENG_6_1 is *not* for stable, RELENG_6 is for stable.
>>     
>
> Yes.	 
> 	(Tricky word stable, I know what you mean, but I've also
> 	seen so called stable that was quite unstable on occasion
> 	way back, when one was ill advised to track beyond fixes
> 	for the specific release that was really `stable' in the
> 	real normal non BSD sense of the word, not some
> 	inter-release-hopefully-maybe-but-sometime-not-stable thing ;-)
>
>   
>> RELENG_6_1 is 
>> the security branch for 6.1-RELEASE,
>>     
>
> Yes.
> 	(& thus more stable (in the real sense of the word) &
> 	invariant than the inter-release progressive RELENG_6 that
> 	FreeBSD names as 'Stable')
>
>   
>> this should be used instead of 
>> RELENG_6_1_1_RELEASE.
>>     
>
> "Could" Yes, "Should" No.  Not always. It's a matter of personal
> requirement that we are not qualified to dictate to others.  Some
> few people may _really_ _want_ exactly the release for their own
> very good reasons eg QA stamped, part of embedded systems with
> expected & tested & timed repose, relied on to interact exactly as
> expected,  or more bluntly, simply 'cos they've been told they'll
> be fired & or imprisoned (eg if in military or high rel. sytems),
> if they change an authorised code base without authority.
>
>
>   
IMHO, that's a very special case. Aside from these kinds of licensing 
hurdles you mentioned as a special example, I still think that the 
security branch should be used. Only very slight changes go to 
RELENG_6_1 that don't cause functional changes. Using 
RELENG_6_1_0_RELEASE anyway is like buying a two-day bread instead of 
the fresh one. The security branch offers the same functionality and 
*quality* that the original release, so imho the other points you listed 
make no sense.

I really don't want to flame about this, but I'm curious what others 
think about this topic, because I'm very convinced that the use of the 
release tag is strongly discouraged after the release. If a security 
hole is recognized why one might not want to patch it?

Gabor Kovesdan