Les Mikesell <lesmikesell@xxxxxxxxx> wrote:
> The part I don't understand is why the tool built for the
> purpose doesn't do what everyone needs it to do.
Like? I'm still trying to find your explanation on this.
So far, you talked about breaking out SPEC files. (WTF?)
> Is that simple enough?
No. Specifics would be very nice.
> Yes, I know I can build my own system.
There is _no_ system to build. I use RPM and YUM directly to
do _all_ I need. I don't know why you even discussed SPEC
files.
Now if you want a way to build a tree of RPM dependencies,
there's several tools for that. But again, a test system and
it's RPM database is all I need to get a package listing.
> I know there are workarounds. I'd rather not.
Like? If you'd explain them, I could understand you better.
> I could keep rolling my own tarballs like I used to also.
??? For what ???
> The question is why everyone who is responding thinks it is
> a good thing or at least expected that a new system
designed
> to manage packages does not do the simple and needed thing
> that cvs has always done to make it possible to make
> updates consistent and repeatable out of a changing
> repository.
First off, you're talking about atomicity. That has *0* to
do with the tools on the client, and 100% to do with the
server. I think you're completely on the _wrong_track_
there, hence your confusion.
Secondly, you _do_ have atomicity _if_ you generate the YUM
repository meta-data _after_ you upload the files. How the
site updates the YUM listing is more of an issue with their
server procedures, _not_ the tools.
YUM repositories are just a package list and related
meta-data which point to files. The atomicity happens at the
server, on how that package list is updated.
--
Bryan J. Smith | Sent from Yahoo Mail
mailto:b.j.smith@xxxxxxxx | (please excuse any
http://thebs413.blogspot.com/ | missing headers)
