SCIENTIFIC-LINUX-DEVEL Archives

January 2012

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Douglas McClendon <[log in to unmask]>
Reply To:
Douglas McClendon <[log in to unmask]>
Date:
Wed, 25 Jan 2012 19:28:09 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (53 lines)
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

ATOM RSS1 RSS2