Feature proposal: Extended Life Cycle Support

[Ding Yi Chen]

----- "Kevin Kofler" <kevin.kofler at chello.at> wrote:

> Ding-Yi Chen wrote:
> > 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?
> 
> As I've tried to explain to you last time you proposed that approach
> on your 
> blog, that approach is completely broken by design and cannot work.
> Please 
> go back to those blog posts and reread my comments. John5432's replies
> here 
> also point out the issues.

I know what you were saying, but like I said to you:
I have such system, I have motivation, I put some effort to try, and I succeed.
I know some can be done and some would have serious consequences.
You, on the other hand, don't have such motivation, never tried seriously,
thus you think everything tend to be broken. :-)

> For example, you suggest blacklisting qt because of the renames, but
> that 
> means NO Qt/KDE app can be upgraded to a supported version. (Fedora 8,
> the 
> last release prior to the renames, is no longer supported.)

If what you require is the latest Qt/KDE, then you may remove it from black-listed.
But mind you, unless you know what you are doing and deal with it carefully,
such action will break KDE3 apps such as kbabel.

Of course, you can develop an ad-hoc logic for Denture to deal this problem,
but currently I have no plan for it.

> 
> You'll find that many of the packages you'll want to upgrade won't
> work 
> because of some blacklisted dependency, 

I know. I wish IBus can run on RHEL5, but it cannot because it requires Python 2.5.
I also know that Denture can tell me that such install/upgrade is not possible
unless I remove Python form black-list and face all the consequences.

> and even where they appear to
> work, 
> they might not actually work (see also John5432's point about
> unspecified  minimum version dependencies). 

If that is the case, either file a bug to the package owners
and ask them to correct the minimum version dependencies if 
the package version is covered by current supported released;
or to Denture to override.

> There's no way to just use the packages
> from 
> a newer distribution on an older one, we have separate branches for a
> reason, there's no way around them. And your idea of cherry-picking 
> individual packages for upgrading is just unsupportable.

Some packages can support the certain older releases, some packages don't.
Blindly assuming all package versions can work with older releases will
surely fail. 

Tell Denture your constraint and
it will build packages if it can; or reasons why it cannot build.
-- 
Ding-Yi Chen
Software Engineer
Internationalization Group
Red Hat, Inc.

Looking to carve out IT costs?
www.apac.redhat.com/promo/carveoutcosts/