clement is a yum repository?

[Jima]

On Fri, 22 Dec 2006, Jean-Marc Pigeon wrote:
> 	You are absolutely right.... But may I suggest you missed
> 	my point altogether....
> 	Clement is not the issue...
> 	The issue is to have in 2 year from now an FC6 in production,
> 	everything is perfect ("if it is working, do not fix it"), but
> 	you still want to keep up-to-date 2 or 3 critical application
> 	(from your production stand-point).
> 	YUM and it is repository system is now a standard.
> 	By setting the clement repos definition , I tried to provide
> 	a way to conveniently go beyond the normal FCX life
> 	cycle. In fact I am trying to resolve a problem of my own
> 	occuring when I want to keep some package Alive (I know some
> 	customer site still running (happily) a RH-6.1 for almost 6 year
> 	now).

  This concept isn't lost on me.  Earlier this year I decommissioned a 
RedHat 6.2 machine that had been not only in place for about six years, 
but hadn't been rebooted in three.
  Alas, it was a foregone conclusion that to keep a machine in place that 
long, we had to give up the luxury of receiving updates (from upstream, at 
least).  That was acceptable for what we needed, so that was okay.  For a 
while.

> 	If, I as provider/designer, I am willing to provide application
> 	X from RH-7.3 -> to XXXX, it is my decision. Having a convenient
> 	yum backup repos implemented within the application seems
> 	to me a solution (may be there is better way (still to
> 	define?)).
> 	According my understanding of the exchange on this topics,
> 	providing a easy/standardized way to go beyond a normal
> 	linux distribution life cycle is out of question.

  As Mr. Keating touched upon, it does no good to end users if one package 
continues to be maintained if hundreds others (many of them probably with 
more potential for serious security vulnerabilities) are not.

> 	Fine to me, but then FC-X is a nice piece of artwork,
> 	but not a distribution to be used for production grad.
> 	(May be RedHat like it that way).

  It's fine as long as you don't have qualms with upgrading to the next 
release.  If that's an issue, then RHEL or CentOS (with their longer 
support cycles) might be better suited to your needs.

>> say on that).  Just keep it out of /etc/yum.repos.d/.  I don't care how
>> confusing it might be to enable it -- how confused do you think we were
>> when we discovered (twice!) that you did such an outlandish thing?
> 	First time I was not advised, if it was that terrible, you
> 	should have let me know, too bad for you.

  I wasn't the one who discovered or remedied it either time, but yes, I 
agree, you should have been specifically contacted.  I'm not attaching any 
particular blame to either instance.  The first, your intentions were 
good; the second, you weren't aware that you were undoing something. 
Alas, FESCo was not fond of the discovery the first time, and there seems 
to be fairly significant opposition to your idea.  I'm fine with people 
extending the life cycle for clement updates, but only if that's 
specifically what they intend to do.  If they skate past EOL and still see 
updates (from clement), they might assume everything is hunky-dory when 
that's anything but the case.

      Jima