Maciej Z.enczykowski wrote:
> There should not be a great space usage associated with
this - you
> only need to store one copy of each rpm/hdr file.
(Unless they
> actually rebuild everything for 5.1... which seems very
unlikely)
> The only actual 'extra' disk storage space would be
cause by storing
> actual iso cd/dvd images - as mentioned many times
before, this can be
> gotten around with jigdo.
>
> 5.0/arch/base - base 5.0 from release time
> 5.0/arch/updates - updates till 5.1 + security updates
to 5.0 past 5.1
> release [no automatic upgrade to 5.1 path]
> 5.1/arch/base - base 5.1 ie. Update 1 from release
time
> 5.1/arch/updates - updates till 5.2 (+ when 5.2 comes
out: security
> updates to 5.1 past the 5.2 release [no automatic
update to 5.2 path]
>
> 5 - symlink which points to current version (ie. 5.0
currently, soon
> 5.1, afterwards 5.2).
>
> You want 5.0? You ask for 5.0, You want 5.newest? You
ask for '5'.
>
> How do you upgrade from 5.0 to 5.1? Either change the
yum repo
> definitions or do a manual rpm -hiv
> http:///
....///centos-release-5.1.noarch.rpm
>
> [remember all rpms/hdrs are hardlinked to each other
were identical
> within multiple 5.x/arch/base,update directories]
We are not talking about 5.1 and 5.2 ... those we do provide
and have a
process for.
We are talking about (if it happens) a 5.0.1 and a 5.1.0
released
simultaneously ... and then later a 5.0.2, 5.1.1, and 5.2
released
simultaneously ... and further on a 5.0.3, 5.1.2, 5.2.1, 5.3
... on and
on 
The problem is that these are ALL different (if they do what
they say).
The whole point of the sub numbers is that the 5.0.x (5.0,
5.0.1, 5.0.2,
5.0.3 in my example) are going to be 5.0 with just security
updates and
things pushed into the 5.0.x tree at that point.
The compiles for the 5.0.x branch would be built via the 5.0
gcc and
glibc forever. Meaning that the 5.1 (or 5.2) gcc/glibc
would not be
used ... so anything new built in 5.1.x (or 5.2.x) and
anything new
built for 5.0.x are built on different gccs and glibcs and
against
different repos (the 5.1 stuff will be built against the new
5.1.x repo
... the 5.0 will be built against only the 5.0.x repo,
etc.). As there
will be different versions of libraries in the different
repos, the
resulting binaries will be different in some cases.
Now ... I have yet to see anything like this actually done
upstream ...
and it is currently just something that the sales people are
saying will
happen. I have not seen anything in RHN implementing this
in practice.
So as someone suggested (Phil I think) ... let's just wait
and see if it
is even done (or if so, in what context it might be done)
upstream.
Thanks,
Johnny Hughes
>
> On 9/7/07, Roger Peņa <orkcu yahoo.com> wrote:
>> --- Phil Schaffner <Philip.R.SchaffnerNASA.gov>
>> wrote:
>>
>>> On Fri, 2007-09-07 at 00:36 +0100, Karanbir
Singh
>>> wrote:
>>>> pushing out each tree, as it is, for upto
3
>>> sub-release deep is just plain
>>>> stupid.
>>> Don't pull any punches now. 
>>>
>>> Seems it could get to more than 3
sub-releases,
>>> unless the upstream
>>> policy is to limit it to the last 3. Witness
3.9
>>> and 4.5.
>>>
>>>> So if anyone has ideas on how we can do
this in a
>>> sane manner, please do
>>>> speak up
>>> Well, how about backing up to the basic
assumptions
>>> before suggesting
>>> solutions. Just because the upstream with
their
>>> much greater (paid)
>>> resources seem to be going to a M.N release
scheme,
>>> is CentOS
>>> constrained to follow precisely in their
footsteps?
>>> What's wrong with
>>> keeping the current scheme of following the
latest
>>> release and
>>> continuing to have M as a pointer to the latest
M.N
>>> tree? If someone
>>> REALLY needs the minor release[es] with
associated
>>> updates, they can go
>>> to the upstream for support; however, I suspect
that
>>> would be a
>>> relatively rare case. If the demand is there
down
>>> the road, can always
>>> re-evaluate the policy.
>> I agree 100%
>>
>> but _if_ centos team whant to provide same taste
as
>> uptream but do not have hardware to support it, I
>> subjest to make a public statement, explaining
that
>> (willing to do but lack of hard) maybe CentOS get
an
>> storage donation to provide that 
>>
>>> So, am I sane?
>> I hope you are, because I agree with your criteria
>>
>> cu
>> roger
_______________________________________________
CentOS-devel mailing list
CentOS-develcentos.org
http://lists.centos.org/mailman/listinfo/centos-devel
|
