[Fedora-livecd-list] patch review and move of livecd scm

[Jeremy Katz]

On Tue, 2007-03-06 at 16:38 -0500, David Zeuthen wrote:
> On Tue, 2007-03-06 at 16:22 -0500, Jesse Keating wrote:
> > That said, I suppose one could define repos at the 
> > cli, but I'd get really tired of typing in 2*N repos (one binary, one source) 
> > for each "repo" I wanted to use (Core, Extras, That which shall not be named)
> 
> For testing, I just have a script that invokes the tool with my chosen
> command line options e.g. my local repositories. 

How is this any better than having a file that you just pass as an
argument to livecd-creator?  I'd say it's _worse_ because you have both
a script and a config that you're maintaining.

> Also, we can add more sugar to the programs as needed, e.g. perhaps
> interactively prompt for the user to add repositories, make the program
> use a mirror list, add an option to use the default repos for release N,
> use the repos that is specified as active in /etc/yum.repos.d (or
> elsewhere)  etc. etc.

I think that a lot of the sugar like this should sit at a higher level
and generate the config.  One tool for one job.  If the lowlevel
livecd-creator bits have to handle all of this, then it just becomes
that much harder to get consistent and reliable output from the tool.
And to do things like integrate it with the buildsystem/rawhide pushes.

In fact, if we have it so that everything about what was used to create
the live CD is in the config file, then we can (and arguably should)
also include the config _on_ the CD.  But if there's a combination of
config file plus whatever arguments someone happened to pass that day,
then it's a lot harder to do that.

> > For that reason, the config files I'd stash in there would be genericized to 
> > point at say the mirror list for Core and Extras, whereas the one used 
> > internally may point to an internal mirror, or something like that.
> 
> Ugh, that sounds really painful. I think, in general, the main point is
> that we don't want the users to edit these files, we want users to trade
> such files with each other and so forth. 

Actually, I want users to share their actual outputs.  And have the
output be fully reproducible without having to know exactly what
arguments I used to a tool

Jeremy