Feature proposal: Extended Life Cycle Support

[John5342]

2009/7/7 Ding-Yi Chen <dchen at redhat.com>:
>
> 於 二，2009-07-07 於 14:44 +0100，John5342 提到：
>> 2009/7/7 Ding-Yi Chen <dchen at redhat.com>:
>> >
>> > 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.
>
> All systems have bugs and may break. So you don't use any of them? :-)

Ofcourse all systems have bugs. However some are minor whilst others
are so much work to make them usable that they are simply not worth
it. Stuff that requires constant user intervention to cope with
scenarios that cannot be automated is one such major issue.

> The scenario you raised could happen if not so many people use the
> package X. Otherwise, it would likely be spot by people who use
> yum update X, as Y-1.3 is not dragged in.
> Given X-1.3 is broken without Y-1.3, thus bug will likely be spot.

Wouldn't be spotted until it is used in your system. It wouldn't be
used during standard usage because in a normal release both would be
updated at the same time (or at least in the right order) so the
scenario never happens.

> Well, Y depends on black-listed packages doesn't mean Y cannot be
> upgraded at all. As long as the the newer Y does not require higher
> version of black-listed packages.

Of course Y can be updated but not necessarily to the required
version. If the world was perfect all versions of packages would
contain the exact versions required for things to work and your
proposed system would either update fine or refuse to with a message
if a dependency is blacklisted or unavailable as a recent enough
version.

However unfortunately for the same reasons i stated already virtually
no package will state the dependant versions accurately enough to do
what you want.

>  But if black-listed packages requires Y, or Y is black-listed,
> then Y will not be upgraded.
> In those cases, it is expected behavior that X should not be upgraded to
> X-1.3 because Y cannot be upgraded to Y-1.3.

That is of course assuming X-1.3 has an explicit dependency on Y-1.3.
It would be lovely if all packages has these versioned dependencies
and a lot have automatically due to things like sonames but take the
scenario where the soname is the same but the presence of the bug is
not.

> Yes, you find out the limitation of Denture, but no,
> Denture is not broken. :-)

Denture is not broken. Unfortunately though Denture only works in the
ideal world. In reality though scenarios like i just mentioned happen
all the time (along with many other similar issues) and the scenario i
mentioned would break the users system and Denture has no way of
knowing until it is too late.

>> 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.
>
> Believe it or not I actually tried something similar,
> but by hand though.
>
> I agree some maintainers does not accurately specify the dependency.
> but it is not beyond fix.

It is not some. It is more like most. How many packages do you see
with the following for every single requires and build requires:
BuildRequires: X-devel = X.X.X-X
Requires: X = X.X.X-X

And packagers shouldnt have to. apart from anything else it would mean
that every single time somebody rebuilds a package all packages that
depend on it would need rebuilding even if the update is binary
compatible yet at the same time the only way to stop the scenario i
mentioned from happening is to do exactly that.

During a normal release bugs are easily spotted and fixed and
scenarios like i mentioned will mostly never even happen anyway but
mixing packages from different releases will potentially create an
infinite number of combinations and almost certainly break.

> One way to overcome this is maintaining a small datafile that contain
> the *true* dependency.
> Denture is not meant to be used to upgrade the whole system,
> but an automated tool to build a target package and corresponding
> mid-packages under specified constrain.
>
> So you only need to correct the dependencies of the target packages and
> mid-packages if you really need the target package.
>
>>
>> --
>> There are 10 kinds of people in the world: Those who understand binary
>> and those who don't...
>>
>
> I like your signature. :-)

Thanks :)

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