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 Development

 
 
LinkBack Thread Tools
 
Old 11-22-2011, 09:27 PM
Tom Sorensen
 
Default moving the CR repo into mainstream release

On Tue, Nov 22, 2011 at 3:00 PM, Marko Bevc <marko@bevc.net> wrote:
> Well my 5c...nothing beeing wrong with CR repo but does it not upstream
> provider(RH) deploys updates as they come?

No. I don't know where people got this idea that RH delivers that way.

When 6.2 comes out (any day now) all of the rpms will be made
available at that time. None of the rpms are pushed into the channel
prior to that.

And unless you do some special foo in RHN your systems will pull down
all of those updates next time you do a "yum update" on them. Or you
can push them to the system from RHN. That makes it no different from
what happens when CentOS makes a point release.

The CR repo is quite different from how RH does it. As I stated
earlier I don't think that there's any significant danger
(particularly compared to having no security updates for months, as is
the current situation with 6) from trickling in RPMs, but it *is*
different from upstream.

Tom Sorensen
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 11-22-2011, 09:58 PM
Gianluca Cecchi
 
Default moving the CR repo into mainstream release

On Tue, Nov 22, 2011 at 11:27 PM, Tom Sorensen wrote:

> When 6.2 comes out (any day now) all of the rpms will be made
> available at that time. None of the rpms are pushed into the channel
> prior to that.
>
> And unless you do some special foo in RHN your systems will pull down
> all of those updates next time you do a "yum update" on them. Or you
> can push them to the system from RHN. That makes it no different from
> what happens when CentOS makes a point release.

Yes,
but after upstream 6.2 has been released you could also run an update
command that is not a fully update, but something like

yum update foo_package

And this command will pull in what is required by rpm configuration in
spec file for foo package + its sub-dependencies.
So, also with upstream, you could be at a certain time, in a mixed 6.1
+ 6.2 level, no guarantee
And for sure upstream can't test every combination of foo update that
doesn't imply the whole 6.2 tree changes applied to your system...

This to say that if CentOS provides an updated package in CR with all
its dependencies we will get the same effect as we would get in
upstream.
If CentOS makes a package foo publicly available but forgets one of
its dependencies (from an rpm chain point of view) you will get an
error when you run the yum command.
(a part from yum/rpm bugs themselves)

Said that, I vote (if I can) for having CR optional and enabled
manually by the user as it is now.

Thanks
Gianluca
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 11-23-2011, 01:28 PM
Leon Fauster
 
Default moving the CR repo into mainstream release

Am 22.11.2011 um 23:58 schrieb Gianluca Cecchi:
> On Tue, Nov 22, 2011 at 11:27 PM, Tom Sorensen wrote:
>
>> When 6.2 comes out (any day now) all of the rpms will be made
>> available at that time. None of the rpms are pushed into the channel
>> prior to that.
>>
>> And unless you do some special foo in RHN your systems will pull down
>> all of those updates next time you do a "yum update" on them. Or you
>> can push them to the system from RHN. That makes it no different from
>> what happens when CentOS makes a point release.
>
> Yes,
> but after upstream 6.2 has been released you could also run an update
> command that is not a fully update, but something like
>
> yum update foo_package
>
> And this command will pull in what is required by rpm configuration in
> spec file for foo package + its sub-dependencies.
> So, also with upstream, you could be at a certain time, in a mixed 6.1
> + 6.2 level, no guarantee


- your scenario would end up in a 6.2 system.

- the description "mixed" misdescribes the actual process

- not all rpms will be updated in a point release.

- a virgin 6.2 installation will install (for sure) a rpm that
also exists in a virgin 6.1 installation.


the point is - that this "mixed" combination is a valid one (validated by upstream).


if the are any dependencies - the "requires/provides" internals of the package system
will push the necessary packages.

by the way - CentOS is explicitly taking care of this linking libs and symbols and etceteras




> And for sure upstream can't test every combination of foo update that
> doesn't imply the whole 6.2 tree changes applied to your system...
>
> This to say that if CentOS provides an updated package in CR with all
> its dependencies we will get the same effect as we would get in
> upstream.
> If CentOS makes a package foo publicly available but forgets one of
> its dependencies (from an rpm chain point of view) you will get an
> error when you run the yum command.
> (a part from yum/rpm bugs themselves)
>
> Said that, I vote (if I can) for having CR optional and enabled
> manually by the user as it is now.


me too


__
LF




_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 11-23-2011, 02:39 PM
Gianluca Cecchi
 
Default moving the CR repo into mainstream release

On Wed, Nov 23, 2011 at 3:28 PM, Leon Fauster wrote:
> - your scenario would end up in a 6.2 system.
>
> - the description "mixed" misdescribes the actual process

>
> the point is - that this "mixed" combination is a valid one (validated by upstream).
>
>
> if the are any dependencies - the "requires/provides" internals of the package system
> will push the necessary packages.

Hi Leon,
actually I have not understood if you agreed with me or not (a part
the vote... ;-)
This is what I mean with "mixed environment" and what I tested
(considered 5.6 --> 5.7 instead of 6.1 --> 6.2)

- install base system from rh 5.6 x86_64 dvd iso
[root@rh56 ~]# uname -r
2.6.18-238.el5

[root@rh56 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.6 (Tikanga)

- register the server with rhn

- update some packages
[root@rh56 ~]# yum update yum
...
Updated:
yum.noarch 0:3.2.22-37.el5

Complete!

[root@rh56 ~]# yum update glibc
...
Updated:
glibc.i686 0:2.5-65 glibc.x86_64
0:2.5-65

Dependency Updated:
glibc-common.x86_64 0:2.5-65 glibc-devel.i386 0:2.5-65
glibc-devel.x86_64 0:2.5-65 glibc-headers.x86_64 0:2.5-65
nscd.x86_64 0:2.5-65

Complete!

[root@rh56 ~]# yum update kernel
...
Installed:
kernel.x86_64 0:2.6.18-274.7.1.el5

Complete!

[root@rh56 ~]# yum update redhat-release
...
Updated:
redhat-release.x86_64 0:5Server-5.7.0.3

[root@rh56 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.7 (Tikanga)

- reboot
[root@rh56 ~]# uname -r
2.6.18-274.7.1.el5

[root@rh56 ~]# rpm -qa|wc -l
442

So, after a pure rh e 5.6 install l I then directly updated 10
packages from rh el 5.7+updates bandwagon...
While the other 432 packages remained as stock rh el 5.6 original dvd

This is what I call a mixed environment....
Note that if I run
[root@rh56 ~]# yum update
I'm proposed this:
...
Transaction Summary
=======================
Install 1 Package(s)
Upgrade 140 Package(s)

Total download size: 116 M
Is this ok [y/N]: Exiting on user Command
Complete!

Is this supported by upstream? I think so.
And the same process would be with CentOS supposing they provided in
CR repo the 10 packages above (actually 9, considering redhat-release
that doesn't carry on any dependencies btw....)

Hope that this explains better my point about mixed-environment, and
the final system not being a 5.7 installation...

Gianluca
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 11-25-2011, 10:39 AM
Leon Fauster
 
Default moving the CR repo into mainstream release

Hi Gianluca,

Am 23.11.2011 um 16:39 schrieb Gianluca Cecchi:
> On Wed, Nov 23, 2011 at 3:28 PM, Leon Fauster wrote:
>> - your scenario would end up in a 6.2 system.
>>
>> - the description "mixed" misdescribes the actual process
>>
>> the point is - that this "mixed" combination is a valid one (validated by upstream).
>>
>> if the are any dependencies - the "requires/provides" internals of the package system
>> will push the necessary packages.
>
> actually I have not understood if you agreed with me or not (a part
> the vote... ;-) This is what I mean with "mixed environment" and what
> I tested
> (considered 5.6 --> 5.7 instead of 6.1 --> 6.2)
>
> <snip>...</snip>
>
> So, after a pure rh e 5.6 install l I then directly updated 10
> packages from rh el 5.7+updates bandwagon...
> While the other 432 packages remained as stock rh el 5.6 original dvd
>
> This is what I call a mixed environment....


i agree with you :-)

To evaluate the implications of the CR repo - like it is or as a
default repo - i suggest to define some major scenarios. The way
people use yum update-commands explicitly/manually will be always
a continuous spectrum (also included: across more then one
releases e.g. "5.3... with the 5.6 glibc").

One scenario would be - a system that has CR enabled and therefore
is in a state that i call e.g "6.(coming release)" minus packages
that are not already build.

One such state was mentioned in this thread. A full updated system
with one (expat) package downgraded. This example had an issue but
not as result of a continuous update.

If there are any real issues - i would like to compile them.
Even the mentioned kernel oops could have there cause elsewhere.

One good thing to keep in mind - the CR rpms passes through a
"stable and completely QA'ed process".



> Is this supported by upstream? I think so.


I would say by design. If a point releases is out (upstream) - the
CR repo is able to provide a package with ALL necessary rpms that
resolves the corresponding dependencies.

Even if kernel-updates of point releases change api's, the dependencies
of userspace (kernel) packages should reflect necessary requirements.


> And the same process would be with CentOS supposing they provided in
> CR repo the 10 packages above (actually 9, considering redhat-release
> that doesn't carry on any dependencies btw....)

thats it.

I understand the mentioned stability hints of some people. I just
want to show up that a reasonable assessment must include the context.
We are not speaking about fedora or other quite interesting distros (as
already mentioned) but about an enterprise distro. This means, it is
fairly stable over the whole lifecycle (centos way to build the distro included).

(Example: Even if a major update is done (php 5.1 -> 5.3) the
"enterprise focus" forces upstream to provide this update as option.


> Hope that this explains better my point about mixed-environment, and
> the final system not being a 5.7 installation...

Sure - and i didn't explain my point of view correctly.


The above is more technicaly. The essential question can not be answered here.
Anyone have to consider there own underlying conditions. Centos can only offer
the options as needed (e.g. CR as option).


That's my EUR 0.01


--
LF


_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 

Thread Tools




All times are GMT. The time now is 10:46 PM.

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