[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Bump CD size in splittree to 685 instead of 640



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 coco merseine nu  Z1aaaaaaa coco merseine nu

Please do not reply off-list


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]