Bryan J. Smith wrote:
> On Fri, 2005-09-09 at 07:39 -0500, Les Mikesell wrote:
>
>>No, it just shows that you don't understand what I said yet.
>
>
> Actually, I don't understand what you're thinking. Then again, I don't
> think you understand how CVS works either.
I think this is a key point in the discussion. I have withheld to
comment on this thread so far, but it is becoming clear that this
fellow has never actually done the work necessary to manage
a released package with hundreds of files and forked ancestry
trees.
Les, what you seem to want is to put a tag on the files so one
can create a snapshot version. A simple date will not do what you
want. I know that you think it will. But I did configuration management
for years, and you just do not have any concept of how difficult
the problem is. You need to think of yum as being a transport agent,
because that's really all it is. Yes, it knows about some dependencies,
but it can't know about everything there is to know.
What you want to happen requires co-ordination between the various
developers, the repository maintainers, the transport/install (yum),
and the users. You are concentrating on the transport/install
tool, and hoping it can do configuration management for you.
I'm here to tell you that I did software development and participated
in configuration management at a large corporation, and we had *teams*
of over 100 engineers and testers working to do what you want, and
we *still* had some holes in the process.
CVS is a pretty weak tool by comparison with what we used. And we found
that the tools we used were still too weak. We had a lot of add-ons
that we did over the standard tools just to allow us to be able to
re-create a given load on demand. We could do it, but it took teams
of engineers, many of whom were dedicated simply to creating packages
which were mutually compatible releases. We had a multitude of
integration testers just to verify that loads worked together.
You need to think of yum as just being a fancy version of wget. You
can ask wget to get a whole web page and its pieces, and it will.
And it'll even resolve some dependencies to fix up the hyperlinks
between the files to fit the structure it builds on your machine.
But that's it. It's a transport mechanism. So is yum. It's a transport.
[snip]
>>All I want is to be able to pretend that additions more recent than
>>a prior run weren't there.
No, that is not what you want. What you expressly requested was to
be able to recreate a yum install, and that the results be consistent.
That requires co-operation all along the whole software development
chain, starting with source, and having a dedicated QA team to create
the certified packages. It requires a certified source library of
all the pieces, and a method for the development tools (compilers,
assemblers, linkers, etc.) to pass along information about what version
went into the build, and the test team to be able to certify
what versions were tested together during integration.
This is inconsistent with "open software development on the web".
It requires a management structure.
> Until you run your _own_ YUM repository and use createrepo a few times,
> you will be oblivious to what a YUM repository is.
I believe you have struck the nail upon the head with perfect
orthogonality.
In fact, he seems to have no concept of what configuration management
is.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!