Les Mikesell <lesmikesell@xxxxxxxxx> wrote:
> Please explain what would go wrong if yum simply ignored
> the presence of files newer than a specified date.
No offense, but build a YUM repository and you'll know
_exactly_ why we think you are _clueless_ in this thread.
The YUM client does _not_ access the RPMs, it accesses the
repodata which is a meta-data listing of what is in the
repository. That meta-data listing is set to a _specific_
set of RPMs at a _specific_ time.
To get what you want, you have to modify the _repository_
end. The YUM client does _not_ and can_not_ arbitrarily
pick'n choose different RPMs that are physically on the
server. It has to rely on the meta-data listing that is on
the server -- generated by another process on the server.
I have described a "hack" that would do what you wish, by
maintaining multiple repodata -- what I call repodelta --
sets. That would be a "nice option" but it can only
regenerate the repodata for the state of the repository when
it is run.
To do anything more advanced, you'd need to delta at least
the headers of the packages in the repository (which would be
the _only_ sane operation IMHO). And when we say "delta" --
we are talking about "CVS-like" operations.
> 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.
Then you need the YUM repository to maintain _multiple_
copies of the repodata from _different_ times. I described
one way this might be done with my "repodelta" conceptual
hack.
> 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.
Then that's what you need to do.
You _can_ feed a filelist into the YUM client.
It's that simple.
What you're talking about requires changes at the repository
end. That is far more involved.
> 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.
You seem to continually be missing the point that the YUM
client does _not_ directly access the RPMs for resolution,
but a meta-data list that is _pre-generated_ at the
repository.
> Then I'm missing why yum would make different decisions
> than it did when the files actually weren't there.
EXACTLY! Becuse you don't understand how YUM repositories
work. Just like you don't understand how delta'ing works.
Hence why this thread never dies, you keep responding to
different people, and some of us (at least me) are too stupid
to just not response (although I think I'm getting smarter, I
think this could be my last post).
> That's all there, and all been done. That's the beauty of
> the current system and the value of using yum in the first
> place.
No, the value of what _you_think_ YUM is.
This is very, very typical of someone who has only used a
client piece of a system, but not actually managed the
service end. In YUM, there is no "YUM service." It is a
tree of files, shared out via HTTP. The YUM client figures
out what is available in the repository by reading the
meta-data that is pre-generated on the server -- *NOT* by
reading the entire YUM repository of RPMs, or otherwise
"interacting" with some "YUM service."
> And that's why I've pressed this conversation this far.
Yes, we know.
> Everything in the repository has already been
> version-numbered, dependency checked and well tested.
At a _single_, _discrete_ point-in-time when the meta-data
was built. It is _neither_ a revisioning back-end _nor_ a
service.
> It's insane to think that I can do a better job of this
> than has already been done.
The problem is that you are assuming what "has already been
done" in YUM, and your assumptions are _dead_wrong_.
> The configuration management is already done.
No it's not! That's the problem.
YUM repositories are a "list of files" with a meta-data
listing "done at date X." Your YUM client does _not_ resolve
by looking through all the RPMs, it resolves by downloading
that meta-data file which was pre-generated on the server.
That meta-data file was created at date X and can offer
_no_other_information_ on the state of the repository at any
other time. The only way around that is to build a _true_
delta'ing backend (version control like CVS) or maintain
multiple copies of the meta-data from different times (which
my conceptual hack suggested).
> All I'm asking for is a way to access what was done last
> week (which is still there)
*WRONG*!
The RPMs are still there, yes.
But the meta-data listing is _not_, it's _gone_.
> 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 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.
And that last option _could_only_exist_ in your mind. ;->
You keep thinking the YUM client can automatically and
arbitrarily pick and choose among RPMs exist in the
repository. The thing is that the YUM client _only_ picks'n
chooses what the meta-data listing says.
And there is _no_ information in that meta-data to say "give
me the state of the repository on date X" if the meta-data
was generated on date Y. There is _no_ "YUM service" on the
server that can dynamically generate this. And the pre-built
meta-data only describes now, because to maintain deltas on
just the repository itself is far more involved (and would
only add to the initial delay).
Which is why I suggested my conceptual "hack." You have to
provide the capability at the repository. Modification of
the YUM client can do _nothing_ with the current way YUM
repositories work. Build a YUM repository and you'll see
_exactly_ what I mean (among others here).
I've explained this enough times. I'll shutup now.
--
Bryan J. Smith | Sent from Yahoo Mail
mailto:b.j.smith@xxxxxxxx | (please excuse any
http://thebs413.blogspot.com/ | missing headers)
