Feature proposal: Extended Life Cycle Support

[John5342]

2009/7/8 Ding Yi Chen <dchen at redhat.com>:
>
> ----- "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. :-)

I don't think this has anything to do with motivation. You have an
idea and on the face of it it sounds great but even the greatest ideas
can be doomed by the details. If you don't believe me (or Kevin) then
go for it and when you get to the details you will see exactly what we
are talking about. We are simply trying to save you the time.

>> 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.

And if you develop ad-hoc logic (which i had too) which is required
for it to come even close to working then who is going to maintain the
data that drives this ad-hoc logic? If you think the users will then
you are likely wrong because the same people who are capable of
helping with this will find it less effort just to use the latest
release and build some compatibility packages for the older stuff.

>>
>> 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.

First of all that largely wouldnt be possible for your proposal. You
also cant account for differences between releases (different releases
can have the same version but entirely different features and
dependencies). Also minimum versions probably aren't enough. You would
also need maximum versions to make your proposal work.

>> 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.

You clearly don't know how many ways a package can fail. There are a
lot of subtle advantages provided by the flow of updates during a
release but Denture will be completely and utterly outside those
comfortable walls.

If you really want a run down of some of the issues you will run into
i can provide although i don't think the list is the place for them.

I can also tell you the far simpler and more effective solution i came
up with for your use case. It is also a frankly much more efficient
use of the time. Instead create a program to generate side by side
installable packages. Then you can use the latest release with all its
features but your old programs that works better on an older Fedora
has all the libs it needs to run. The whole concept is more efficient,
easier to test, less likely to break systems, less dependent on the
user, the type of user in your use case could deal with it more
easily, etc and it also covers most of your use cases on your blog.

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