Feature proposal: Extended Life Cycle Support

[Ding Yi Chen]

----- "John5342" <john5342 at googlemail.com> wrote:

> 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?
> :-)
> 
> Of course 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.

Firstly, not all people turn the automatic upgrade on.
Secondly, there are folks use rpm -hiv or build from srpm.
In that case, they are more likely to spot the bugs.

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

If what you said is completely true, I would not even bother to propose Denture. :-)
> >  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.

If X-1.3 does not specify Y-1.3 as dependency, I don't think
yum update X will pull Y-1.3, even with the current version.
Not to mention people who use rpm directly or build from srpm.
So please file bug to X, don't blame Denture.

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

So do other package managers.
Tell me, why are you so sure that the current version packages 
don't break the system secretly and user and the package managers
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

After a quick peek of the packages I maintain or am interested in:

7 packages provide the version info of each dependency.
5 packages provide the version info for some critical package (see dvdauthor.spec for example).
5 packages does not specified it at all. 3 of which are man-pages :-)

Only 15% of the packages (exclude the man-pages) does not provide any version information.
It may show the laziness of upstream or maintainer, but most of the case,
it's meant to work with older version.

> And packagers shouldnt have to. 

What? Why? Does it logical to expect a stable system if 
critical dependency information is missing?

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

Yes, but let the computer to the rebuilding while you enjoy the result. :-)
Is a rebuilding bad thing? According to my FreeBSD experience, not at all.

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

If this is true, then Denture can happily live with it.
Almost certainly break? You mentioned that 
you did have similar system, if it almost certainly break,
how come you still like the idea?

BTW, mind sharing your program? :-)

-- 
Ding-Yi Chen
Software Engineer
Internationalization Group
Red Hat, Inc.

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