On 01/25/2012 03:41 PM, Michael Tiernan wrote: > On 1/25/12 4:19 PM, Michael Tiernan wrote: >> On 1/24/12 4:26 PM, Connie Sieh wrote: >>> Why can you not fix it until the "next distribution" comes out? > > Not intending to insult anyone's intelligence, using the "A picture is > worth a 1K words" approach: > http://dl.getdropbox.com/u/27834209/The_Problem.png > It is a small drawing that might help folks quickly see the point I was > after. Just to ensure clarity, 'The Problem' that I was verbosely discussing in another branch of this thread, while related to the above problem, is quite different. Just for the record, I would describe 'A Problem' that I'm trying to solve as this- TUV releases and long-term-supports an unarguably useful Linux distro. They have gone to great lengths with things like rpm/specs, mock, pungi, livecd-creator/tools, towards allowing end-users/the-public to regenerate what they distribute, from conveniently available sources mirrored for instance at ftp://mirrors.kernel.org/pub/redhat. Unfortunately, though the automated build environments and tools they have provided do automate 99.9% of the cryptic commands needed to build their distro, the remaining 0.1% is still remarkably complex, and subtely error prone. Likewise, if users _do_ overcome the undocumented steps needed (and neigh, multitude of alternate paths that all variously produce varyingly sufficient output), they still cannot redistribute their output in the spirit of the GPL due to entirely reasonable trademark issues. Now, over the last 5 years, fedora/redhat have gone to great lengths to automate away, again 99% of the trouble of doing that. But again, the remaining 1% is undocumented, with varying alternatives with varying levels of sufficiency. Thus the problem I'm pushing towards solution, came to mind as simply an input/processing/output computer problem. I.e. there is this hunk of source-form input at mirrors.kernel.org/pub/redhat/etc, and I'd like to simply have a script/program that fetches that. Then a seperate program or phase of the program that, on an offline system with that input fetched, can then go and verify signatures, and build it exactly as it should be (or have configurability to easily select amongst debatable alternatives for the way people think it should be built), and then, a few days/weeks later, have output sitting in front of you that you can publicly redistribute to others, without having to ask anyone's permission. And while that might not be a problem that millions, or even thousands of people have, I think that solving it for the dozens of groups that have it, will ultimately indirectly benefit thousands and millions of users. $0.02... -dmc