FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 09-09-2011, 01:16 AM
Always Learning
 
Default Emulate RHEV On CentOS - A note on Xen v. KVM

On Thu, 2011-09-08 at 20:00 -0400, Ross Walker wrote:
> On Sep 7, 2011, at 9:57 AM, Always Learning <centos@u61.u22.net> wrote:
>
> > Perhaps a silly question, but why maintain patches ? Why not compile a
> > new version and discard all the patches ? Patches are a messy manner to
> > maintain programmes.

> RHEL needs to keep the same ABI (application binary interface) for both
> kernel and user programs so third party VARs and software developer's
> binary packages will continue to be compatible during the lifetime of
> a release (5.X or 6.X).

According to my brief 30 seconds understanding of ABIs from Wikipedia,
that does not seem relevant to patching. The ABI is just a calling
convention. The parameters used and the data exchanged is predetermined
otherwise nothing would work. Parameters and data formats remains
constant throughout the life-time of the software. That has always been
the way for all inter-programme communications.

> In order to do that RH keeps (or makes all attempts to) the same
> versions of the software during the release while back porting
> security updates and must-have features that don't change these ABIs.

Anything which is patched is, by definition, not the same version as the
original version although the version number can remain the same and the
functionality generally remains the same. Obviously the ABI should
remain the same otherwise other programmes would be unable to
successfully exchange 'data'.

> These back ported updates are the patches that are applied to the base
> package.

Which means some systems, patched locally, may have to then re-apply
their patches to the base system ?

> That should make it crystal clear.

Regrettably it did not. Another poster, whose name I can't recall at
this moment, explained the patched practise as being able to restrict
charges to specific modules while maintaining unaltered core
functionality and having the flexibility to customise a base package for
specific requirements.

Best regards,

Paul.



_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-09-2011, 04:20 AM
Ross Walker
 
Default Emulate RHEV On CentOS - A note on Xen v. KVM

On Sep 8, 2011, at 9:16 PM, Always Learning <centos@u61.u22.net> wrote:

>
> On Thu, 2011-09-08 at 20:00 -0400, Ross Walker wrote:
>> On Sep 7, 2011, at 9:57 AM, Always Learning <centos@u61.u22.net> wrote:
>>
>>> Perhaps a silly question, but why maintain patches ? Why not compile a
>>> new version and discard all the patches ? Patches are a messy manner to
>>> maintain programmes.
>
>> RHEL needs to keep the same ABI (application binary interface) for both
>> kernel and user programs so third party VARs and software developer's
>> binary packages will continue to be compatible during the lifetime of
>> a release (5.X or 6.X).
>
> According to my brief 30 seconds understanding of ABIs from Wikipedia,
> that does not seem relevant to patching. The ABI is just a calling
> convention. The parameters used and the data exchanged is predetermined
> otherwise nothing would work. Parameters and data formats remains
> constant throughout the life-time of the software. That has always been
> the way for all inter-programme communications.

Ok, let's say version X of a given software package has a security flaw in it. This security flaw has been fixed in version Y of the same package, but version Y has a slightly different functionality, maybe it is in some shared libs or maybe just in how it presents itself in procfs/configfs.

Now RH needs to fix this security flaw in the existing version X of the package, this package's existing interface needs to remain constant because software vendors have products out there that depend on it, so they reverse engineer or diff out the changes made to fix the security flaw without making any of the functionality changes.

This then becomes a patch to the existing version X. It is applied as a patch in the SRPM because it's easy to incorporate, track, document and back-out if necessary.

Over time the software packages and the kernel itself will accumulate multiple patches.

>> In order to do that RH keeps (or makes all attempts to) the same
>> versions of the software during the release while back porting
>> security updates and must-have features that don't change these ABIs.
>
> Anything which is patched is, by definition, not the same version as the
> original version although the version number can remain the same and the
> functionality generally remains the same. Obviously the ABI should
> remain the same otherwise other programmes would be unable to
> successfully exchange 'data'.

Yes, RH packages are NOT the same as the originals, they have security patches and maybe some performance fixes from the originals, but they keep the ABI the same, and thus keep the version numbers the same. There are version numbers appended to the upstream version to differentiate the packages and determine the fix level of a given package through it's lifetime.

>> These back ported updates are the patches that are applied to the base
>> package.
>
> Which means some systems, patched locally, may have to then re-apply
> their patches to the base system ?

No, these patches are incorporated into the SRPMs used to build the binary RPM packages and they become the distribution, after a certain amount are accumulated they re-target the distribution at a point release 5.1, 5.2, etc.

>> That should make it crystal clear.
>
> Regrettably it did not. Another poster, whose name I can't recall at
> this moment, explained the patched practise as being able to restrict
> charges to specific modules while maintaining unaltered core
> functionality and having the flexibility to customise a base package for
> specific requirements.

I'm sorry I wasn't very clear to begin with, maybe this helped?

-Ross

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-09-2011, 09:06 PM
"James B. Byrne"
 
Default Emulate RHEV On CentOS - A note on Xen v. KVM

On 01/-10/-28163 02:59 PM, Always Learning wrote:
>
> On Thu, 2011-09-08 at 20:00 -0400, Ross Walker wrote:
>> On Sep 7, 2011, at 9:57 AM, Always Learning<centos@u61.u22.net> wrote:
>>
>>> Perhaps a silly question, but why maintain patches ? Why not compile a
>>> new version and discard all the patches ? Patches are a messy manner to
>>> maintain programmes.
>
>> RHEL needs to keep the same ABI (application binary interface) for both
>> kernel and user programs so third party VARs and software developer's
>> binary packages will continue to be compatible during the lifetime of
>> a release (5.X or 6.X).
>
> According to my brief 30 seconds understanding of ABIs from Wikipedia,
> that does not seem relevant to patching. The ABI is just a calling
> convention. The parameters used and the data exchanged is predetermined
> otherwise nothing would work. Parameters and data formats remains
> constant throughout the life-time of the software. That has always been
> the way for all inter-programme communications.
>
>> In order to do that RH keeps (or makes all attempts to) the same
>> versions of the software during the release while back porting
>> security updates and must-have features that don't change these ABIs.
>
> Anything which is patched is, by definition, not the same version as the
> original version although the version number can remain the same and the
> functionality generally remains the same. Obviously the ABI should
> remain the same otherwise other programmes would be unable to
> successfully exchange 'data'.
>
>> These back ported updates are the patches that are applied to the base
>> package.
>
> Which means some systems, patched locally, may have to then re-apply
> their patches to the base system ?
>
>> That should make it crystal clear.
>
> Regrettably it did not. Another poster, whose name I can't recall at
> this moment, explained the patched practise as being able to restrict
> charges to specific modules while maintaining unaltered core
> functionality and having the flexibility to customise a base package for
> specific requirements.

Generally the reason that packages on RHEl have patches back-ported
instead of simply updated to the latest version is because of the
version dependencies other packages may have. The entire RHEL
distribution, as are most others, is pervasively permeated by intricate
package inter-dependencies. Changing the version number of one may well
start a cascade of failed dependencies in other, apparently unrelated
packages.

Also, the idea of backward API compatibility is not given much
consideration in many FOSS projects in my experience. Injecting a new
version of some software into the distribution may well disable parts of
it that depend upon a now deprecated function.

It is well to remember that the reason new versions of RHEL take so long
to appear is the effort that goes into making sure that every package
contained therein will build and inter-operate correctly with all of the
others. No-one concerned with getting it to work in the first place
really wants to introduce potentially substantial changes.


--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 11:33 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org