Jesse Keating wrote:
On Saturday 20 January 2007 21:38, John Summerfield wrote:
I'm looking at splittree in FC6; it's hard-coded to 640*1024.0*1024, and
I don't see a way to override it.
I contend it should be specifiable from the commandline, and the default
value be set in a configuration file for the distro. The config file
might also specify the product name (RHEL, FC, Clark Connect etc) and
release.
And all this info should go into the first ISO image so folk can easily
see how to recreate it, create modified versions etc etc. Of course,
this is all beyond the scope of changing CD size....
In the compose tools we use, we don't call splittree directly, rather we
import splittree as a module and set some variables that way, then call
splittree.timber().
The particular compose tool I'm working on, pungi, will have the configurable
items in a config file, to allow for easy reproduction. I don't necessarily
think they belong on the CD itself, as much of the config will be specific to
the compose environment, which may not necessarily match what is external
(repo locations, compose destination, etc..).
One of the big problems folk have had wrt Anaconda for years has been
lack of documentation.
I will admit right now that I haven't gone looking for official
documentation recently, it's a while since I found the need to remaster
a {RHL,RHEL,Fedora} ISO, and it may have improved. I'm guessing it
hasn't though, these things tend to get left until later by many,
including JS.
Some folk here will remember Tony Nugent who became famous for writing
the best document for remastering RHL back in the time of RHL 7.x.
I think the position could be alleviated greatly, if RH included a
script that could be run by users to take a source tree of built RPMs
and create one or more ISO images ready to burn.
The script would need to be parameterised, perhaps as simply as setting
some values (probably those used by RH), and then sourcing a file in
{$PWD,$HOME}, so as to account for different users' setups: we may store
the tree differently, we may store source packages in a completely
different location.
Oh, this does not prevent RH from using its own private tools; the
script should be produced by those tools (and maybe in time those tools
could be extended to generate the script and then use it).
Why should RH do this? Well, obviously to extend its niceness:-)
It's nice that this is in Fedora Core 6:
[summer@ns ~]$ head -20 /misc/fc6/GPL
*****************************************************************************
The following copyright applies to the Red Hat Linux compilation and any
portions of Red Hat Linux it does not conflict with. Whenever this
policy does conflict with the copyright of any individual portion of Red Hat
Linux, it does not apply.
*****************************************************************************
It would be nicer still if RH bound itself to the terms of the GPL and
provided scripts to "to control compilation and installation of the
executable."
--
Cheers
John
-- spambait
1aaaaaaa@xxxxxxxxxxxxxxxx Z1aaaaaaa@xxxxxxxxxxxxxxxx
Please do not reply off-list
