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

Re: [Fedora-livecd-list] Support for custom configuration using python templates



On Thu, 2007-04-26 at 21:44 -0400, David Zeuthen wrote:
> On Thu, 2007-04-26 at 16:51 -0400, John (J5) Palmieri wrote:
> > > I think munging configuration files might be outside the scope of the
> > > livecd-tools project; sure, granted it's something people want to do but
> > > often it's used as a hack; for example on my system 
> > > 
> > >  $ rpm -qf /etc/issue
> > >  fedora-release-6.93-1
> > 
> > And I'm going to package that up for every daily release?  And what
> > about countries? Too heavy and engineered for an image based
> > distribution.
> 
> [...]
> 
> > > so I think what you *could* do instead is to have olpc-release or
> > > similar on OLPC provide that file (would be based on fedora-release). Of
> > > course, since /etc/issue is marked as %config(noreplace) in the
> > > fedora-release it's still sane for you to edit it in %post. I guess it
> > > all depends on the configuration file in question.
> 
> I think I said that both approaches works. Just make sure all files
> being changed are tagged with %config(noreplace) if you care about RPM
> upgrade paths (which you probably don't need to for OLPC but it's nice
> nonetheless if someone wants to pick this up for hardware that can cope
> with yum/rpm etc.).
> 
> > > So I think my point of view right now is that it's good enough to do
> > > this in %post for most cases; I mean, if downstreams (like OLPC) need to
> > > change a ton of configuration files/defaults perhaps there is something
> > > broken with the apps you try to include? 
> > 
> > No just that apps can be configured for different purposes.  For
> > instance gedit can be made into a development environment but requires
> > me to write out a bunch of gconf files.  We have Sabyon for a reason.
> > It basically does what I want to do in the case of gconf and some other
> > settings.  It is a dump of configuration files.
> 
> Sure, or you can use gconftool-2 or Puppet as Mark mentioned or
> basically anything that gets the job done. My point really was that I
> don't think configuration file munging belongs in livecd-tools proper.
> Do you think that's wrong?
> 
> > > Perhaps you can come up with concrete examples of what configuration
> > > files / defaults you need to edit /change? I think that would be useful.
> > > Thanks.
> > 
> > /etc/sysconfig/modules/olpc-1.modules for the module lists to load
> > /etc/rwtab for stateless tmpfs mounted stuff
> > /etc/asound.state to put the correct default sound levels
> > /etc/modprobe.d/olpc.conf.dist so we get the correct module parameters
> > /boot/olpc_build for build info that the bootloader uses
> > /etc/issue for build info the user can read
> > /etc/securetty for adding the serial console
> > /etc/inittab for removing unneeded memory waisting VT's
> > /usr/share/fonts/dejavu-lgc/fonts.dir for mapping legacy fonts
> > /usr/share/fonts/dejavu-lgc/fonts.scale same as above
> > /usr/share/fonts/dejavu-lgc/fonts.alias same
> > /etc/X11/xorg.conf and its variants for booting on any device and
> > getting the correct xorg config file with the correct keyboard laysouts
> > /home/olpc/.xinitrc for launching sugar
> > /boot/grub/grub.conf for the occasional qemu boot
> > /etc/init.d/olpc-configure init script for boot time configuration
> > /usr/share/X11/xkb/symbols/* for keyboard configuration that is not yet
> > upstream (note that these must be added to an already existing file)
> > /boot/olpc.fth - for booting from openfirmware
> > 
> > Note that we can't move a lot of these to an RPM because RPM conflict
> > rules would prevent them from being installed.  Some files need input
> > such as BUILD number and some files change so rapidly during the testing
> > phase that taking the time to build an rpm and place it in the right
> > spot and rebuild the repo would be a unneeded bottleneck.
> 
> So perhaps one maintainable way for you is to have a single script
> (packaged up in a OLPC specific RPM) that does all the munging and your
> %post simple invokes this? That script would know about per-country
> things and what kind of "image" (e.g. jffs2, livecd, disk_ext3 etc.)
> you're building by having the %post pass it as options? Wouldn't that
> work? 
> 
> Of course, the question I raised in an earlier mail of how we pass items
> to the %post script in the Kickstart file still stands. Jeremy? Perhaps
> just setting environment variables works out of the box. I'd be
> surprised if this is not the case.
> 
> Also, external variables used by higher level constructs that does batch
> builds in a structured way (e.g. pilgrim-autobuild) needs to pass
> (OLPC-specific) variables too such as BUILD_NUMBER, TARGET_COUNTRY etc.
> to %post. I think the way I'd like this to work is that such variables
> are transparently passed by livecd-tools and then the %post takes care
> of it. Perhaps it would look like this
> 
>   %post
>   olpc-configure-system --image-type $LIVECD_TOOLS_IMAGE_TYPE \
>                         --olpc-build-number $OLPC_IMAGE_NUMBER \
>                         --olpc-target $OLPC_TARGET_COUNTRY
> 
> Would that work for you?

In some ways it does but then again it isn't a standard solution but
just a workaround. It still means no quick turnaround for testing but
that is all a failing of our build system.  

%post to me is a workaround all together.  I would really have liked
this to be more declarative, then tools could be written which had
context to what is going on instead of this RPM black box.  A couple of
things are already declarative in ks such as turning on and off default
init scripts.  I would have liked to have had more intelligent systems.
For instance with the RPM method inheritance is at the whim of how the
post in the RPM is written.  For the most part people will get it right
but there is also the issue that I can't optimize either.  If it was
declarative a tool could say this file is going to be overwritten by a
later declaration so there is no need to write it out.

I guess I am in a camp which believes we need to get away from the
flexibility of scripting around deficiencies in our higher level tools
and instead make the tools more robust and able to handle the corner
cases.



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