Feature proposal: Extended Life Cycle Support

[John5342]

2009/7/7 Ding-Yi Chen <dchen at redhat.com>:
>
> 於 日，2009-07-05 於 12:32 +0200，Jeroen van Meeuwen 提到：
>> On 07/05/2009 12:12 PM, Jos Vos wrote:
>> > On Sun, Jul 05, 2009 at 12:03:05PM +0200, Jeroen van Meeuwen wrote:
>> >
>> >> The CentOS project, or it's upstream, has a release cycle of approximately
>> >> three years -not a steady release cycle of three years but that's what it
>> >> turns out to be. This disqualifies the distribution(s) as desktop Linux
>> >> distributions, as desktops tend to need to run the latest and greatest for
>> >> as far the latest and greatest lets them.
>> >
>> > I don't completely agree that "desktops tend to need to run the latest and
>> > greatest" (when we're talking about business desktops), but desktops
>> > (especially also when talking about laptops because of HW compatibilities)
>> > need newer software than RHEL offers, based on now 3 year old base versions
>> > of most packages (except Firefox and a few others).
>> >
>>
>> Agreed, I exaggerated a little there ;-) What I meant is they tend to
>> need to run the latest and greatest *compared* to servers, and as you
>> said, especially laptops and newer hardware.
>>
>> -- Jeroen
>>
>
> Usually, people stick with older releases because they like to keep some
> packages/applications which are known to works on those releases.
>
> On the other hand, they may still want to upgrade other packages to
> obtain security fixes or crucial features.
>
> But the problem is, there is no unanimous way to determine what packages
> to keep and what packages to update, so generic Fedora legacy repository
> might not provide much help for those people, who actually need the
> legacy support.
>
> Therefore, I would like to propose an alternative approach,
> namely, project Denture. See my blog post for further information:
> http://dingyichen.livejournal.com/14055.html
>
> Any comments?

In theory your proposal sounds great but i see just one major flaw
that probably doesn't have a solution. Your idea of packages being
built based on dependencies should work great apart from the fact that
most packages don't tend to have hard dependencies on versions.
Hypothetically in F11 package X-1.2.X relies on package Y-1.2. Later
in the release cycle Y-1.3 is released followed later by X-1.3. Eve
though X-1.3 actually requires Y-1.3 the maintainer probably never
thinks to update the required version (assuming there even was one in
the first place). Now your system can easily fail. It picks X-1.3 from
F-11 (because thats the latest one) but Y-1.3 isn't allowed (because
one of its dependencies is black listed) so it falls back to Y-1.2
which was the latest in F-10. Everything builds fine because they are
source compatible but Y-1.2 doesnt have a crucial bug fixed. Now your
software is broken.

Believe it or not i actually tried something similar for some of my
internal servers and i like the idea but its impossible to get the
dependencies right which makes the whole idea a no go.

-- 
There are 10 kinds of people in the world: Those who understand binary
and those who don't...