5:33 p.m.
Here`s my livecd config file format proposal.
We`ve been talking about reusing kickstart file format, but I found
out that it`s not so good solution. Kickstart file doesn`t include
complete list of packages but keeps only list of groups to be included
and relies on comps.xml file and definitions of group members. Since
it`s very important for config files to be compatibile with different
versions of FC, we have to have the complete list of packages in our
config file (for example, some 100MB big package could be added to
some group we included, and the size of our livecd iso image would
change dramaticly without a reason). Again, for compatibility reasons,
we have to keep the list of packages _without_ version numbers
inluded.
Many repositories can be listed in config file, but only one (named
"default") is essential. URL parameter for repositories is read from
conf file by default, but can be overriden with command line parameter
(for example: buildlivecd -f ./fc4livecd.conf -r
default=http://bla.bla/fedora/core/4 ).
I think that layout used in this example that I`m sending is not the
best choise, and the reason I used it is to describe the hierarchy of
the file. So, please, propose some file layout that could have similar
structure but that can be easily parsed by both python application
that is supposed to generate it and bash script that is supposed to
read information from it. And, yes, feel free to post your comments :)
Darko
12:38 a.m.
On 7/17/05, Darko Ilic <darko.ilic(a)gmail.com> wrote:
Here`s my livecd config file format proposal.
We`ve been talking about reusing kickstart file format, but I found
out that it`s not so good solution. Kickstart file doesn`t include
complete list of packages but keeps only list of groups to be included
and relies on comps.xml file and definitions of group members.
The kickstart file format supports excluding files from the default
base set and including individual packages from other groups. The
"Package Selection" tab of the kickstart gui tool is currently group
limited but could be enhanced to support individual selection. The
post-install script can also be used to add and remove packages from a
repository.
The kickstart gui and file format provides a lot of other
configuration information in addition to language and package
selection. For dedicated enterprise applications, specific network and
authentication methods may need to be built into the CD. Many other
kickstart options and switches are available that can drive a fully
automated image build with Anaconda.
So, please, propose some file layout that could have similar
structure but that can be easily parsed by both python application
that is supposed to generate it and bash script that is supposed to
read information from it.
Several build approaches have been discussed on the list and via IRC.
Just to clarify, have we abandoned the idea of using the kickstart gui
for generating the build file and Anaconda for building the image?
-Tom
6:47 a.m.
On Monday 18 July 2005 07:38, Tom Lisjac wrote:
The kickstart file format supports excluding files from the default
base set and including individual packages from other groups. The
Yes, but what if comps.xml changes? For example, type of package A could be
changed from optional to mandatory, and we will have it included in our
LiveCD without intetion...
The kickstart gui and file format provides a lot of other
configuration information in addition to language and package
selection. For dedicated enterprise applications, specific network and
authentication methods may need to be built into the CD. Many other
kickstart options and switches are available that can drive a fully
automated image build with Anaconda.
But we decided that image build won`t be done by anaconda. The concept can be
seen on http://fedoraproject.org/wiki/LiveCD.
Darko
2:04 p.m.
On Mon, 2005-07-18 at 13:47 +0200, Darko Ilic wrote:
On Monday 18 July 2005 07:38, Tom Lisjac wrote:
> The kickstart file format supports excluding files from the default
> base set and including individual packages from other groups. The
Yes, but what if comps.xml changes? For example, type of package A could be
changed from optional to mandatory, and we will have it included in our
LiveCD without intetion...
Unless you're planning on ignoring package dependencies, the same could
happen due to packages having new dependencies. Going off and defining
your own thing is likely to make things far less adaptive as changes
occur to Fedora Core as now instead of just the comps file having to
change, the live cd stuff will need to change also.
> The kickstart gui and file format provides a lot of other
> configuration information in addition to language and package
> selection. For dedicated enterprise applications, specific network and
> authentication methods may need to be built into the CD. Many other
> kickstart options and switches are available that can drive a fully
> automated image build with Anaconda.
But we decided that image build won`t be done by anaconda. The concept can be
seen on http://fedoraproject.org/wiki/LiveCD.
This means that you're going to have to be able to duplicate all of the
setup types of tasks which anaconda does as well as duplicate all of the
system level setup changes which occur on a per release basis :/
Jeremy
2:39 p.m.
All right, so we immediately have a philosophical question, right up
front, that we must address:
Should we use anaconda wherever possible? And are we making a mistake by
not using anaconda?
The upside of using anaconda is that it's the center of a whole bunch of
stuff, and it's guaranteed to be maintained going forward.
What are the downsides of using anaconda?
--g
_____________________ ____________________________________________
Greg DeKoenigsberg ] [ the future masters of technology will have
Community Relations ] [ to be lighthearted and intelligent. the
Red Hat ] [ machine easily masters the grim and the
] [ dumb. --mcluhan
On Mon, 18 Jul 2005, Jeremy Katz wrote:
On Mon, 2005-07-18 at 13:47 +0200, Darko Ilic wrote:
> On Monday 18 July 2005 07:38, Tom Lisjac wrote:
> > The kickstart file format supports excluding files from the default
> > base set and including individual packages from other groups. The
>
> Yes, but what if comps.xml changes? For example, type of package A could be
> changed from optional to mandatory, and we will have it included in our
> LiveCD without intetion...
Unless you're planning on ignoring package dependencies, the same could
happen due to packages having new dependencies. Going off and defining
your own thing is likely to make things far less adaptive as changes
occur to Fedora Core as now instead of just the comps file having to
change, the live cd stuff will need to change also.
> > The kickstart gui and file format provides a lot of other
> > configuration information in addition to language and package
> > selection. For dedicated enterprise applications, specific network and
> > authentication methods may need to be built into the CD. Many other
> > kickstart options and switches are available that can drive a fully
> > automated image build with Anaconda.
>
> But we decided that image build won`t be done by anaconda. The concept can be
> seen on http://fedoraproject.org/wiki/LiveCD.
This means that you're going to have to be able to duplicate all of the
setup types of tasks which anaconda does as well as duplicate all of the
system level setup changes which occur on a per release basis :/
Jeremy
--
Fedora-livecd-list mailing list
Fedora-livecd-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-livecd-list
6:39 p.m.
On 7/18/05, Greg DeKoenigsberg <gdk(a)redhat.com> wrote:
Should we use anaconda wherever possible? And are we making a
mistake by
not using anaconda?
Anaconda/kickstart already does 98% of the heavy lifting that's needed
for a top quality CD build tool. Taking a little more time to discuss
it might keep us from reinventing the wheel. I think it's a good
choice because:
- it can accept a flexible config file and produce highly customized
images from a variety of package repositories.
- it has a gui for building images interactively for both the
configuration and build phases.
- it's an existing, production quality system that is well known,
widely used and thoroughly documented.
- it can execute pre and post install scripts (using any interpreter)
to provide CD image customization to any degree that is needed.
What are the downsides of using anaconda?
It will have to be modified.
It's always more fun to start with a blank page rather then modify
somebody else's code. Unfortunately many new and creative ideas get
stuck inside buggy, half finished projects because building, refining
and documenting a complete package like Anaconda is a *lot* of work.
The bottom line is how much time do we have to get this project
finished... and how much of that time should be spent duplicating
large portions of an existing system that a lot of people already use
and like?
-Tom
9:26 p.m.
On Monday 18 July 2005 15:04, Jeremy Katz wrote:
On Mon, 2005-07-18 at 13:47 +0200, Darko Ilic wrote:
>
> But we decided that image build won`t be done by anaconda. The concept
> can be seen on http://fedoraproject.org/wiki/LiveCD.
This means that you're going to have to be able to duplicate all of the
setup types of tasks which anaconda does as well as duplicate all of the
system level setup changes which occur on a per release basis :/
That was one of the reasons for me to 'clone' anaconda: to try to develop
modules that could be used as some kind of 'snap in' to extend the normal
(and thoroughly tested) install process with functions to put that
installation into a livecd.
Since anaconda provides everything to safely install into a dircetory/harddisk
from a parent system... well - one of my secret dreams was (is?) to have
'livecdinstall' as just another type of install aviable in anaconda ...
Perhaps it is possible to use the anaconda codebase at least for the initial
installation of the 'master' system - even if the livecd-installer is not
included in anaconda (and does not have any gui/wizards):
The image creation would be run by an external script - as defined in the
concept.
Imho that could/would safe a lot of manpower: we get a proper install 'for
free' and just have to create the tool to modify and put it onto a cd/dvd
media.
With two configfiles (one beeing the default kickstart and one as the
livecd-build config file) we would also guarantee that every livecd system
can easely be installed to harddisk.
Jeremy
Dirk *leaning out of the window, so hit me now* Westfal
9:48 p.m.
Dirk Westfal wrote:
On Monday 18 July 2005 15:04, Jeremy Katz wrote:
>On Mon, 2005-07-18 at 13:47 +0200, Darko Ilic wrote:
>
>
>
>>But we decided that image build won`t be done by anaconda. The concept
>>can be seen on http://fedoraproject.org/wiki/LiveCD.
>>
>>
>This means that you're going to have to be able to duplicate all of the
>setup types of tasks which anaconda does as well as duplicate all of the
>system level setup changes which occur on a per release basis :/
>
>
That was one of the reasons for me to 'clone' anaconda: to try to develop
modules that could be used as some kind of 'snap in' to extend the normal
(and thoroughly tested) install process with functions to put that
installation into a livecd.
Since anaconda provides everything to safely install into a dircetory/harddisk
from a parent system... well - one of my secret dreams was (is?) to have
'livecdinstall' as just another type of install aviable in anaconda ...
Perhaps it is possible to use the anaconda codebase at least for the initial
installation of the 'master' system - even if the livecd-installer is not
included in anaconda (and does not have any gui/wizards):
The image creation would be run by an external script - as defined in the
concept.
Imho that could/would safe a lot of manpower: we get a proper install 'for
free' and just have to create the tool to modify and put it onto a cd/dvd
media.
With two configfiles (one beeing the default kickstart and one as the
livecd-build config file) we would also guarantee that every livecd system
can easely be installed to harddisk.
>Jeremy
>
>
Dirk *leaning out of the window, so hit me now* Westfal
--
Fedora-livecd-list mailing list
Fedora-livecd-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-livecd-list
Hello,
You should just use as much as possible the Fedora Core installation
scripts. Just add an extra RPM (to the Fedora Core distribution) to
replace the kernel with a bootcd kernel (which supports unionfs and
squashfs), and an RPM containing the busybox startup stuff (I am working
on this for the yataa project, I have made the bootcd kernel RPM and
will soon start the bootcd RPM) see http://dc.qut.edu.au/yetaa
--
regards Neville
-----------------------------------------------------------------------
email: n.richter(a)qut.edu.au room: S745 Gardens Point
phone: +61 7 3864 1928 fax: +61 7 3221 2384
web: http://dc.qut.edu.au/sedc/staff/neville_richter.html
Neville Richter, Senior Lecturer
School of Software Engineering & Data Communications
Faculty of Information Technology
Queensland University of Technology
Box 2434 Brisbane 4001 AUSTRALIA
7:27 a.m.
On Mon, 18 Jul 2005, Jeremy Katz wrote:
> But we decided that image build won`t be done by anaconda. The
concept can be
> seen on http://fedoraproject.org/wiki/LiveCD.
This means that you're going to have to be able to duplicate all of the
setup types of tasks which anaconda does as well as duplicate all of the
system level setup changes which occur on a per release basis :/
Also, it seems to me that at least in some respects changes to anaconda
for CD aren't that different from changes to anaconda for populating Zen
images....
later,
chris
6855
days inactive
6857
days old
livecd@lists.fedoraproject.org
8 comments
7 participants
participants (7)
-
Chris Ricker -
Darko Ilic -
Dirk Westfal -
Greg DeKoenigsberg -
Jeremy Katz -
Neville Richter -
Tom Lisjac