Les Mikesell lesmikesell@gmail.com 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.