Les Mikesell wrote:
> On Fri, 2005-09-09 at 12:05, Mike McCarty wrote:
>
>
>>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.
>
>
> Please explain what would go wrong if yum simply ignored the
> presence of files newer than a specified date.
Please explain to me how the date of a file describes its contents.
Until you can tell me how, merely by looking at the date of a file,
one can know what its contents are, then you haven't shown how
by using dates one can get yum to do consistent downloads.
>>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.
>
>
> I'm not asking to deal with arbitrary revisions to same-named
> files here. I'm asking for repeatable actions with all the
> same stuff available plus possibly some new things I'd prefer
> to ignore. Everything still exists in the repository and
> would be available if you extracted the version numbers from
> the machine with the prior run with rpm -q and fed it explicitly
> to yum to install. If there is a reason that yum would not
> make exactly the same decision again by itself if it just
> could be told to ignore the subsequently-added files in the
> repository I am missing something.
If that's what you want, then the easiest way is simply to
create your own repository. Use anything to create the repository,
starting empty. Then draw only from that repository. This requires
no cooperation between you, the developers, the repository
maintainers, or anyone else. You will be in complete control.
No changes to yum, or rsync, or any other tool is required. You
can write a script which does the creation. Start the script and
walk away. Have it e-mail you when it completes.
One day you decide you want to update some machines in a repeatable
(though not necessarily consistent) manner. Start with an empty
repository, and use any method you like to fill it. Then do
all updates from that repository.
But, IIRC, you said yourself you wanted *consistency*. And that
cannot be done simply.
>>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.
>
>
> The only new thing I'm asking is for it to pretend some new files
> weren't there.
The easiest way to do that is not to have those files exist. And
using a date is not a reliable way to guarantee content.
>>>>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.
>
>
> Then I'm missing why yum would make different decisions than it
> did when the files actually weren't there.
Perhaps you are using the word "consistent" in a way I don't understand.
Do you mean "repeatable" or do you mean "consistent"?
Either way, a file timestamp does not guarantee content.
[snip]
>>>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.
>
>
> The configuration management is already done. All I'm asking for is
Not by using a timestamp it isn't.
> a way to access what was done last week (which is still there) and
> ignore available additions. Yes it can be done with a complete
> snapshot of every repository state that I might want to repeat
> an update from. It could also be done by making a snapshot of
A snapshot is just that. What you want is named snapshots. And that
is configuration management.
> a current repository and physically removing the files I don't
> want yet. It could also be done if the yum program just ignored
> the files I don't want yet. The last option just seems nicer.
How can yum know what files you want to ignore, unless it has
version tags associated, and a named version for the entire
build?
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!
