[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Feature proposal: Extended Life Cycle Support

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

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

What you said is true, but since what Denture is for unsupported 
released, which is unlikely getting any updated. Your case is not suitable
for unsupported release.

> > 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 the fact does not cover all packages, so that's why I need Denture,
and take the risk. That's also life. :-)

> 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 I could hit the bump, so are the guys that using source build and other distribution
which have not yet put Y-1.3 to their repos.

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

I also states my justification why the packages should
specify the exact depended versions. 
> You have found the exceptions there. Try looking at some others.

I see. What I mainly need Denture help is for end-user applications.
I am not quite sure about using Denture for library or toolkit directly.
> 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?

BuildRequires:  libdvdread-devel >= 0.9.4-4
BuildRequires:  libxml2-devel >= 2.6.0

Without these, dvdauthor might break even within current release.
You were saying that version is not important?  :-)

Nevertheless, you raise a valid point that version information 
is sometime unavailable or unreliable.

But this can be overcome by a datafile that stores correct version.

> 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

For people who requires absolute stable, they can just use CentOS/
RHEL and totally ignore Denture.

Denture is for the people that need to keep some critical packages,
but wouldn't mind to take some risk. :-)

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

"Whatever" is possibly the problem.
Denture only eats what it can eat.  :-)
According to my experience, some of the dreams can come true.

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

Please don't assume that I am not aware your concerns.
Did you see my answers about them? 

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

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

Looking to carve out IT costs?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]