Feature proposal: Extended Life Cycle Support

[John5342]

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

I am not talking about upgrades. I am talking about updates. Most
people just run updates when packagekit (or similar) tells them to. In
a proper release updates are released together. In Denture they will
be updated out of order and from various different releases. As for
people rebuilding from srpms etc they represent a minority and it is
in any case irrelevant.

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

What i said is plain and simple fact. The scenario i mentioned is one
of several points of failure. I am not suggesting it is a problem with
Denture itself but it is a problem with the real world. Thats just
life.

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

This isn't about whether Y-1.3 will be pulled in. If you do what the
vast majority of users do then you will get the equivelant of yum
update. Regardless of whether X-1.3 explicitly specifies Y-1.3. Y-1.3
will still be updated siply because there is a later version. When you
update using Denture however you could easily end up with X-1.3 and
Y-1.2 for any number of reasons.

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

If you read all i wrote then you will find that has been answered
thoroughly already

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

You have found the exceptions there. Try looking at some others.

>> And packagers shouldnt have to.
>
> What? Why? Does it logical to expect a stable system if
> critical dependency information is missing?

I am sure even your dependency versions become stale. Taking your
example of dvdauthor
BuildRequires:  libpng-devel
BuildRequires:  flex
BuildRequires:  bison
BuildRequires:  fribidi-devel
BuildRequires:  freetype-devel
BuildRequires:  GraphicsMagick-devel
BuildRequires:  autoconf automake gettext-devel

In a single release you perhaps can be pretty sure that the versions
in the build root are good enough to satisfy dvdauthor. If on the
other hand you end up with a version of one of these packages from a
previous release due to blacklisting then things may well start to
break.

Would you however insist that all of these are bugs?

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

The result could be great but i can be pretty sure that the actually
stability of a partially updated system is probably much worse than
rawhide and people who are happy with that level of stability would
ore than likely just prefer actual recent release

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

I like the idea because the concept is great. The idea that you can
run whatever version of whatever package you want and get the best of
all worlds is a nice dream but unfortunately i also know that it is
only a dream and in real life it simply can't work because the huge
requirements that Denture would place on packaging just can't be done.
If nothing else because of manpower. Most maintainers wont have time
to test every possible combination of versions accross multiple
releases just so that Denture stands a chance of working.

When i was working on my project i quickly realised that for the
reasons i have been trying to explain (falling on deaf ears
apparently) and many others besides it simply wasn't feasible. It
could be done but the effort of maintaining the fedora packages to a
level that would allow Denture to work would probably require double
the package maintainers we already have. Good luck with that one.

> BTW, mind sharing your program? :-)

I probably have it somewhere on backup but i never bother restoring
backups of projects that are doomed to failure. If i ever come across
the backup i will send it you but i don't see much point in searching
through Exabytes of data just for that.

I really wish you all the best. I really do. I would love to be
surprised and see it work but i won't be holding my breath. Good luck!

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