(adding back fedora-desktop-list as that Cc: field mysteriously vanished.)
On Wed, 2006-09-20 at 03:05 -0500, Jasper Hartline wrote:
You really should use the stock Fedora Core utilities however. If you are making an installer to system from LiveCD, why not use Anaconda?
I'd rather ask; Why use anaconda? At the end of the day, installation is a pretty basic task
- yum install what you want - write out some configuration files - perform other post-installation configuration.
So, you know, I'd hate to replace < 100 lines of code by depending on anaconda, which, I might add, is designed to do far more than the relatively straightforward task of doing live cd's. I'm not even sure it makes sense to carry around code in anaconda to facilitate live cd installs but I'll leave that judgement call to the Anaconda developers.
FWIW, yum works perfectly fine and one goal of the pilgrim effort is to make the process as robust as possible as well as being able to run on host OS'es that are not super current. For example, the image I linked to are built on an x86_64 RHEL4 box (though I had to put yum 2.9.* on it).
There's also an historical angle here - pilgrim is the successor to the now defunt olpc-image tools. Anaconda simply didn't allow to be used in this way.
If OLPC is a "derived" from Redhat or Fedora Core distribution, I really do not see how this pertains to this list.
I think Rahul answered this already. I'll also note that this is not a kadishchi specific list (or at least that's my impression) and several people have asked me to specifically post my work here.
On another note, what functionality does this LiveCD stuff you mention provide over Fedora Core's Kadischi? If you are unfamiliar with Kadischi, you can find it here: http://fedoraproject.org/wiki/Kadischi Available via CVS.
I think there are some key differences
- specifically designed to be able to install the livecd payload on your hard disk. I've read through the archives of this list and seen objections from Jeremy and others about the feasibility of changing Kadischi to facilitate this. Pretty sure there are few objections to the approach I've taken with pilgrim but I'll leave Jeremy to comment.
- designed specifically with downstream consumers in mind, e.g. it must be extremely simple to put together an Fedora Eclipse, Fedora Music, Fedora Livna Desktop, whatever live cd. This is what I tried to describe in my original mail.
- r/w root so the OS actually works like it's supposed to (with the live cd ISO that I linked to you can easy yum install what you want or perhaps even use pirut)
- Use selinux - ok, so I ran into some issues with enabling this (see the README.fedora file) so it's disabled in the ISO I linked to. However, if your build environment matches the target environment this works nicely. I'll be working on fixing this, certainly OLPC needs this feature anyway.
- the codebase pilgrim is based on have been used successfully to build OLPC images for many months now. Pilgrim have now replaced this and is a critical component of the OLPC release infrastructure. As such, I and others are committed to maintaining pilgrim for at least this task.
So these are the key differences I think.
You probably know how it is with software development. People will use your software in unforeseen ways. As such, as software developers we tend to make our software prepared to do this. I just happened to identify a huge overlap between what we're doing in OLPC and what a nice livecd infrastructure should look like. So I spent a day or two making pilgrim doing just this.
Hope this clarifies.
David
David Zeuthen wrote:
(adding back fedora-desktop-list as that Cc: field mysteriously vanished.)
On Wed, 2006-09-20 at 03:05 -0500, Jasper Hartline wrote:
You really should use the stock Fedora Core utilities however. If you are making an installer to system from LiveCD, why not use Anaconda?
I'd rather ask; Why use anaconda? At the end of the day, installation is a pretty basic task
- yum install what you want
- write out some configuration files
- perform other post-installation configuration.
So, you know, I'd hate to replace < 100 lines of code by depending on anaconda, which, I might add, is designed to do far more than the relatively straightforward task of doing live cd's. I'm not even sure it makes sense to carry around code in anaconda to facilitate live cd installs but I'll leave that judgement call to the Anaconda developers.
FWIW, yum works perfectly fine and one goal of the pilgrim effort is to make the process as robust as possible as well as being able to run on host OS'es that are not super current. For example, the image I linked to are built on an x86_64 RHEL4 box (though I had to put yum 2.9.* on it).
There's also an historical angle here - pilgrim is the successor to the now defunt olpc-image tools. Anaconda simply didn't allow to be used in this way.
David,
How do you plan on performing upgrades when the live cd gets a install to hard disk feature?
Rahul
On Wed, 2006-09-20 at 20:43 +0530, Rahul wrote:
How do you plan on performing upgrades when the live cd gets a install to hard disk feature?
Well, I've written about that in the README.fedora file. Lemme cut'n'paste so people can rip it apart. It's basically just a braindump, I haven't written code for this just yet (patches welcome!).
So.. my plan basically just involves running 'yum -y update' in the chroot you install to. Not sure we need any UI, some progress feedback would be nice, not sure if yum can do that already. Seth?
Specifically this means that once you boot into the installed OS all updates will have been applied. Clearly this requires network connectivity but such is life. I also expect that it's feasible to do e.g weekly livecd respins we in four months ppl downloading the "FC6 Desktop" livecd will already get the updates minus perhaps a week. But they'll be able to update.
- Can probably start writing the scripts and UI that will wrap libraries from gnome-diskutil. Suggest this script This script should
Also
- take some parameters --target-partition=/dev/sda1 --install-bootloader-at-mbr=true|false --fs-label=LabelToUseForFS [--swap-device=/dev/sda2] --i18n=da_DK.UTF-8 --root-passwd (probably safer to pass it on stdin)
- verify that target partition given is large enough
- dd the ext3 fs over to the target partition
- resize2fs the fs
- mount this at /mnt/target
- delete files specific to livecd; that is
- /mnt/target/etc/udev/rules.d/00-livecd.rules
- /mnt/target/etc/init.d/livecd
- /mnt/target/etc/rc5.d/livecd
- (TODO: keep this list in sync with script and with what junk we put in the pristine ext3 fs.)
- rewrite /mnt/target/etc/sysconfig/i18n
- rewrite /mnt/target/etc/fstab (if no swap device is given use a swap file on the target fs. No, Swap Files Are Not Evil(tm), get over it :-)
- run /sbin/mkinitrd in the /mnt/target chroot
- set the root password
- touch a file on /mnt/target so firstboot is run (TODO: need to either put firstboot on the live cd or make firstboot redundant.)
- write /mnt/target/boot/grub/grub.conf
- run /sbin/grub-install from /mnt/target/ chroot
- run 'yum update' in the /mnt/target chroot if we have network connectivity. This is to update the installed OS with the latest security / feature patches etc. etc.
- probably need to include yum-updatesd but disable at livecd usage since the install system will need it
- script should be invoked via a D-BUS system bus service so the GUI bits for doing the install become trivial
- provide reasonable progress feedback / error reporting
- need to write this tool with paranoia in mind; we're talking about messing with people's data here
Cheers, David
On Wed, 2006-09-20 at 11:53 -0400, David Zeuthen wrote:
On Wed, 2006-09-20 at 20:43 +0530, Rahul wrote:
How do you plan on performing upgrades when the live cd gets a install to hard disk feature?
Well, I've written about that in the README.fedora file. Lemme cut'n'paste so people can rip it apart. It's basically just a braindump, I haven't written code for this just yet (patches welcome!).
So.. my plan basically just involves running 'yum -y update' in the chroot you install to. Not sure we need any UI, some progress feedback would be nice, not sure if yum can do that already. Seth?
Specifically this means that once you boot into the installed OS all updates will have been applied. Clearly this requires network connectivity but such is life. I also expect that it's feasible to do
Right; we certainly can't fit all Fedora Core packages on one LiveCD, since a LiveCD is obviously only _one_ CD. So you'd never be able to upgrade off packages from a CD. Furthermore with Extras its highly likely that people have packages from Extras, and that doesn't fit on a CD either.
About the only reasons you might _ever_ want to update from a LiveCD are (a) to test your hardware with the new kernel, and to (b) see what new apps and features are around, before you actually do the update. I don't see what is all that useful about doing the actual update from from the LiveCD itself though, versus rebooting and running a small tool to pull down new .repo files and doing the equivalent of 'yum update' which other tools already do for us.
What's the use-case here for update from a LiveCD anyway? Why?
Dan
e.g weekly livecd respins we in four months ppl downloading the "FC6 Desktop" livecd will already get the updates minus perhaps a week. But they'll be able to update.
- Can probably start writing the scripts and UI that will wrap libraries from gnome-diskutil. Suggest this script This script should
Also
- take some parameters --target-partition=/dev/sda1 --install-bootloader-at-mbr=true|false --fs-label=LabelToUseForFS [--swap-device=/dev/sda2] --i18n=da_DK.UTF-8 --root-passwd (probably safer to pass it on stdin)
- verify that target partition given is large enough
- dd the ext3 fs over to the target partition
- resize2fs the fs
- mount this at /mnt/target
- delete files specific to livecd; that is
- /mnt/target/etc/udev/rules.d/00-livecd.rules
- /mnt/target/etc/init.d/livecd
- /mnt/target/etc/rc5.d/livecd
- (TODO: keep this list in sync with script and with what junk we put in the pristine ext3 fs.)
- rewrite /mnt/target/etc/sysconfig/i18n
- rewrite /mnt/target/etc/fstab (if no swap device is given use a swap file on the target fs. No, Swap Files Are Not Evil(tm), get over it :-)
- run /sbin/mkinitrd in the /mnt/target chroot
- set the root password
- touch a file on /mnt/target so firstboot is run (TODO: need to either put firstboot on the live cd or make firstboot redundant.)
- write /mnt/target/boot/grub/grub.conf
- run /sbin/grub-install from /mnt/target/ chroot
- run 'yum update' in the /mnt/target chroot if we have network connectivity. This is to update the installed OS with the latest security / feature patches etc. etc.
- probably need to include yum-updatesd but disable at livecd usage since the install system will need it
- script should be invoked via a D-BUS system bus service so the GUI bits for doing the install become trivial
- provide reasonable progress feedback / error reporting
- need to write this tool with paranoia in mind; we're talking about messing with people's data here
Cheers, David
Dan Williams wrote:
On Wed, 2006-09-20 at 11:53 -0400, David Zeuthen wrote:
On Wed, 2006-09-20 at 20:43 +0530, Rahul wrote:
How do you plan on performing upgrades when the live cd gets a install to hard disk feature?
Well, I've written about that in the README.fedora file. Lemme cut'n'paste so people can rip it apart. It's basically just a braindump, I haven't written code for this just yet (patches welcome!).
So.. my plan basically just involves running 'yum -y update' in the chroot you install to. Not sure we need any UI, some progress feedback would be nice, not sure if yum can do that already. Seth?
Specifically this means that once you boot into the installed OS all updates will have been applied. Clearly this requires network connectivity but such is life. I also expect that it's feasible to do
Right; we certainly can't fit all Fedora Core packages on one LiveCD, since a LiveCD is obviously only _one_ CD. So you'd never be able to upgrade off packages from a CD. Furthermore with Extras its highly likely that people have packages from Extras, and that doesn't fit on a CD either.
About the only reasons you might _ever_ want to update from a LiveCD are (a) to test your hardware with the new kernel, and to (b) see what new apps and features are around, before you actually do the update. I don't see what is all that useful about doing the actual update from from the LiveCD itself though, versus rebooting and running a small tool to pull down new .repo files and doing the equivalent of 'yum update' which other tools already do for us.
This method is not widely documented or easy to use yet AFAIK.
What's the use-case here for update from a LiveCD anyway? Why?
Basically. My interest in having a install/upgrade from a Live CD is directly related to http://fedoraproject.org/wiki/Distribution/FreeMedia.
Fedora is currently 5 CD's/ One DVD and this is expected to grow once when have Fedora Extras on the media too which might be as soon as FC7 since its kind of a prerequisite for this - http://fedoraproject.org/wiki/UnleashKDE. In effect we might see the number of CD's double or even more.
A useful desktop set requires the first two CD's in Fedora through the Anaconda method and you can only perform a minimalistic installation from a single CD. Currently we are distributing DVD's in Free media program instead which is a problem in many regions where DVD drivers and media is costly and not widely used. Magazines and books prefer to distribute distributions which have a single CD more often to reduce their costs. There is also a perception of "bloat" related to the number of CD's.
In events and for Freemedia distributions it would much more effective to hand out a single live CD with a hard disk installation feature. Of course people might want more software and they would have to grab it off the internet or some other distribution mechanism but a single installalable live CD covers the typical use case and promotional needs.
Once this method is propagated and commonly used, users would already have installations which they would want to upgrade later. Having this functionality in a Live CD would mean that I could just forget about Anaconda in Fedora and stick with a Live CD for all my needs which is confined to a desktop and grabbing stuff on demand off the network.
Rahul
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Rahul escribió:
Once this method is propagated and commonly used, users would already have installations which they would want to upgrade later. Having this functionality in a Live CD would mean that I could just forget about Anaconda in Fedora and stick with a Live CD for all my needs which is confined to a desktop and grabbing stuff on demand off the network.
- From a user's perspective, Anaconda could be used for the "full version", i.e the DVD or full set of CDs composing the totality of Fedora, while you can simply install (I hate saying this, but again, like Ubuntu) from one of the various liveCDs/LiveDVDs... Only prerequisite I see in this approach is to have a means to either:
- - have all the necessary .repo files already in place, so when the installation is performed, and the user might want additional software, (s)he could simply fire up pirut, and all the headers would be updated "automagically" and the software retrieved from the repositories; or
- - have a minimum set of .repo files, and a routine in yum, so that when either run from the CLI or with pirut or even pup, the necessary repos get installed (sort of a "first-update" operation, a la first boot configuration), and the system updated/ready to install new software.
I'd lean more towards the former approach, as simple text files don't take too much space, especially since they can compress so well. The problem would then be deciding which repos to include, as it would rock if livna-release package was available in Extras to be able to grab packages from Livna (with a big Red Flag of Warning, if you will), but sort of make it so that the end users wouldn't have to mess and fetch the keys and packages manually, etc, etc.
Just my 2¢.
On Wed, 2006-09-20 at 23:04 +0530, Rahul wrote:
Dan Williams wrote:
On Wed, 2006-09-20 at 11:53 -0400, David Zeuthen wrote:
On Wed, 2006-09-20 at 20:43 +0530, Rahul wrote:
How do you plan on performing upgrades when the live cd gets a install to hard disk feature?
Well, I've written about that in the README.fedora file. Lemme cut'n'paste so people can rip it apart. It's basically just a braindump, I haven't written code for this just yet (patches welcome!).
So.. my plan basically just involves running 'yum -y update' in the chroot you install to. Not sure we need any UI, some progress feedback would be nice, not sure if yum can do that already. Seth?
Specifically this means that once you boot into the installed OS all updates will have been applied. Clearly this requires network connectivity but such is life. I also expect that it's feasible to do
Right; we certainly can't fit all Fedora Core packages on one LiveCD, since a LiveCD is obviously only _one_ CD. So you'd never be able to upgrade off packages from a CD. Furthermore with Extras its highly likely that people have packages from Extras, and that doesn't fit on a CD either.
About the only reasons you might _ever_ want to update from a LiveCD are (a) to test your hardware with the new kernel, and to (b) see what new apps and features are around, before you actually do the update. I don't see what is all that useful about doing the actual update from from the LiveCD itself though, versus rebooting and running a small tool to pull down new .repo files and doing the equivalent of 'yum update' which other tools already do for us.
This method is not widely documented or easy to use yet AFAIK.
What's the use-case here for update from a LiveCD anyway? Why?
Basically. My interest in having a install/upgrade from a Live CD is directly related to http://fedoraproject.org/wiki/Distribution/FreeMedia.
Fedora is currently 5 CD's/ One DVD and this is expected to grow once when have Fedora Extras on the media too which might be as soon as FC7 since its kind of a prerequisite for this - http://fedoraproject.org/wiki/UnleashKDE. In effect we might see the number of CD's double or even more.
Right; I'm not questioning the use of a LiveCD _install_. I completely agree there. I'm questioning the use of a LiveCD _upgrade_.
dan
A useful desktop set requires the first two CD's in Fedora through the Anaconda method and you can only perform a minimalistic installation from a single CD. Currently we are distributing DVD's in Free media program instead which is a problem in many regions where DVD drivers and media is costly and not widely used. Magazines and books prefer to distribute distributions which have a single CD more often to reduce their costs. There is also a perception of "bloat" related to the number of CD's.
In events and for Freemedia distributions it would much more effective to hand out a single live CD with a hard disk installation feature. Of course people might want more software and they would have to grab it off the internet or some other distribution mechanism but a single installalable live CD covers the typical use case and promotional needs.
Once this method is propagated and commonly used, users would already have installations which they would want to upgrade later. Having this functionality in a Live CD would mean that I could just forget about Anaconda in Fedora and stick with a Live CD for all my needs which is confined to a desktop and grabbing stuff on demand off the network.
But it's not clear to me why you'd want to upgrade from a LiveCD rather than just boot into your already-installed image and do a 'yum upgrade'. There's _nothing_ that a LiveCD-based install process would consist of other than a 'yum upgrade', except that you're running off the livecd.
I guess there is a 'seamless' aspect to this, such that you can use the same CD for both the update payload (the new .repo files) and test the hardware in the same bootup. I'm not sure if the small benefit of doing everything in the same boot outweighs the disadvantage of complicating the CD with update logic which could just as easily be done in the real system, since both LiveCD and real system would end up running 'yum upgrade' anyway.
Dan
Dan Williams wrote:
But it's not clear to me why you'd want to upgrade from a LiveCD rather than just boot into your already-installed image and do a 'yum upgrade'. There's _nothing_ that a LiveCD-based install process would consist of other than a 'yum upgrade', except that you're running off the livecd.
Well you to have go grab fedora-release from the latest Fedora, install it and then run yum upgrade and pray that it works. We havent made it very simple nor do we test it explicitly for every release that things work well after a yum upgrade.
If we make this very simple for a new user to follow, then maybe we wouldnt need a upgrade through live cd option. Currently, thats not the case.
Rahul
On Wed, 2006-09-20 at 13:19 -0400, Dan Williams wrote:
What's the use-case here for update from a LiveCD anyway? Why?
I think the question was about upgrading the packages _from_ the livecd when they are installed (if you have an old livecd); not about using the livecd to upgrade an existing installation. For the latter you'd just be using yum [1].
David
[1] : Or anaconda... until we fix Fedora etc. to support upgrades from e.g. FC5 -> FC6 using yum - something we badly need anyway and hardly any news
On Wed, 20 Sep 2006, David Zeuthen wrote:
If OLPC is a "derived" from Redhat or Fedora Core distribution, I really do not see how this pertains to this list.
I think Rahul answered this already. I'll also note that this is not a kadishchi specific list (or at least that's my impression) and several people have asked me to specifically post my work here.
Yes. In fact, I hounded David relentlessly for a couple of weeks to publicize his work here, because I think it's excellent.
It's natural to be skeptical of new code, but bear these facts in mind:
1. PRIORITY.
Kadischi is heavily reliant upon Anaconda. Anaconda's functionally is a large superset of Kadischi's. Anaconda also has significant *business* pressures on its roadmap. Kadischi patches are, therefore, low priority for Anaconda developers.
Pilgrim, on the other hand, performs *extremely* similar tasks for OLPC. OLPC must be imaged very simply, and very uniformly. A Live CD/Live DVD is the same.
2. INSTALL FUNCTIONALITY.
If there's one place where Ubuntu has an *actual* lead on us, it's in their ability to install a Live CD directly to a system. From what I've seen, we're closer to closing that gap with Pilgrim than we are with Kadischi.
3. COMMUNITY DEVELOPMENT.
I'd like to see the prominent developers on this list -- Chitlesh, Jasper, jdog, and others I've surely left out -- have commit access. With Anaconda, that simply can't happen. With Pilgrim, it might.
===
These three facts, in my mind, are reason enough to ask the Fedora Live CD community to consider the benefits of Pilgrim. If we want to develop the two technologies side-by-side, that's fine too. But this is the fedora-livecd-list -- *not* the kadischi list.
--g
------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors -------------------------------------------------------------
On Wed, 2006-09-20 at 11:29 -0400, Greg DeKoenigsberg wrote:
On Wed, 20 Sep 2006, David Zeuthen wrote:
If OLPC is a "derived" from Redhat or Fedora Core distribution, I really do not see how this pertains to this list.
I think Rahul answered this already. I'll also note that this is not a kadishchi specific list (or at least that's my impression) and several people have asked me to specifically post my work here.
Yes. In fact, I hounded David relentlessly for a couple of weeks to publicize his work here, because I think it's excellent.
It's natural to be skeptical of new code, but bear these facts in mind:
- PRIORITY.
Kadischi is heavily reliant upon Anaconda. Anaconda's functionally is a large superset of Kadischi's. Anaconda also has significant *business* pressures on its roadmap. Kadischi patches are, therefore, low priority for Anaconda developers.
Pilgrim, on the other hand, performs *extremely* similar tasks for OLPC. OLPC must be imaged very simply, and very uniformly. A Live CD/Live DVD is the same.
- INSTALL FUNCTIONALITY.
If there's one place where Ubuntu has an *actual* lead on us, it's in their ability to install a Live CD directly to a system. From what I've seen, we're closer to closing that gap with Pilgrim than we are with Kadischi.
Interesting question; does Ubuntu's LiveCD allow a user to upgrade a currently hard-disk-installed Ubuntu to the Ubuntu version that's booted from the LiveCD, like you would do a clean install? Or do they punt that functionality?
Dan
- COMMUNITY DEVELOPMENT.
I'd like to see the prominent developers on this list -- Chitlesh, Jasper, jdog, and others I've surely left out -- have commit access. With Anaconda, that simply can't happen. With Pilgrim, it might.
===
These three facts, in my mind, are reason enough to ask the Fedora Live CD community to consider the benefits of Pilgrim. If we want to develop the two technologies side-by-side, that's fine too. But this is the fedora-livecd-list -- *not* the kadischi list.
--g
Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors
Dan Williams wrote:
On Wed, 2006-09-20 at 11:29 -0400, Greg DeKoenigsberg wrote:
On Wed, 20 Sep 2006, David Zeuthen wrote:
If OLPC is a "derived" from Redhat or Fedora Core distribution, I really do not see how this pertains to this list.
I think Rahul answered this already. I'll also note that this is not a kadishchi specific list (or at least that's my impression) and several people have asked me to specifically post my work here.
Yes. In fact, I hounded David relentlessly for a couple of weeks to publicize his work here, because I think it's excellent.
It's natural to be skeptical of new code, but bear these facts in mind:
- PRIORITY.
Kadischi is heavily reliant upon Anaconda. Anaconda's functionally is a large superset of Kadischi's. Anaconda also has significant *business* pressures on its roadmap. Kadischi patches are, therefore, low priority for Anaconda developers.
Pilgrim, on the other hand, performs *extremely* similar tasks for OLPC. OLPC must be imaged very simply, and very uniformly. A Live CD/Live DVD is the same.
- INSTALL FUNCTIONALITY.
If there's one place where Ubuntu has an *actual* lead on us, it's in their ability to install a Live CD directly to a system. From what I've seen, we're closer to closing that gap with Pilgrim than we are with Kadischi.
Interesting question; does Ubuntu's LiveCD allow a user to upgrade a currently hard-disk-installed Ubuntu to the Ubuntu version that's booted from the LiveCD, like you would do a clean install? Or do they punt that functionality?
Dan
They punt it currently.
Rahul
Dan Williams (dcbw@redhat.com) said:
Interesting question; does Ubuntu's LiveCD allow a user to upgrade a currently hard-disk-installed Ubuntu to the Ubuntu version that's booted from the LiveCD, like you would do a clean install? Or do they punt that functionality?
Is this really wanted functonality? I would think that this is much better left to yum/anaconda.
Bill
On Wed, 2006-09-20 at 11:29 -0400, Greg DeKoenigsberg wrote:
I'd like to see the prominent developers on this list -- Chitlesh, Jasper, jdog, and others I've surely left out -- have commit access. With Anaconda, that simply can't happen. With Pilgrim, it might.
Sure, I'm all for that and am hopeful to get contributors besides myself. Would have to review patches etc. on list since other projects such as OLPC depends on pilgrim. But that's no different from other open source projects.
The first step towards that, and something I'd like anyway, is moving the pilgrim git repository from my home directory on freedesktop.org to Fedora infrastructure. Any pointers to how I do that? Thanks.
David
On 9/20/06, David Zeuthen davidz@redhat.com wrote:
Sure, I'm all for that and am hopeful to get contributors besides myself. Would have to review patches etc. on list since other projects such as OLPC depends on pilgrim. But that's no different from other open source projects.
After reading all these mails :), i'll tend to say that pilgrim's yum approach sounds great. Yum's new metaparser might play a great role as well. However, anaconda provides kickstart file feature to kadischi and this is greatly used by people in the fedora-livecd list.
Sure, I'm not saying that kadischi has to adapt itself to pilgrim's theory. But since, kadischi is only maintained for the moment by Jasper and I at a very slow rate, it would be best to consider on what
* what is Kadischi, by the Fedora Project * which one should be a Fedora Live image Creator/Installer * how both pilgrim and kadischi can benefit.
Ill try pilgrim this weekend.
The first step towards that, and something I'd like anyway, is moving the pilgrim git repository from my home directory on freedesktop.org to Fedora infrastructure. Any pointers to how I do that? Thanks.
is it possible to have under svn ? :p i've cvs access blocked over my place.
David, is your presentations available for download ? I'll like to have a look at them :)
Chitlesh
On Thu, 2006-09-21 at 00:31 +0200, Chitlesh GOORAH wrote:
On 9/20/06, David Zeuthen davidz@redhat.com wrote:
Sure, I'm all for that and am hopeful to get contributors besides myself. Would have to review patches etc. on list since other projects such as OLPC depends on pilgrim. But that's no different from other open source projects.
After reading all these mails :), i'll tend to say that pilgrim's yum approach sounds great. Yum's new metaparser might play a great role as well. However, anaconda provides kickstart file feature to kadischi and this is greatly used by people in the fedora-livecd list.
Sure, I'm not saying that kadischi has to adapt itself to pilgrim's theory. But since, kadischi is only maintained for the moment by Jasper and I at a very slow rate, it would be best to consider on what
- what is Kadischi, by the Fedora Project
- which one should be a Fedora Live image Creator/Installer
- how both pilgrim and kadischi can benefit.
implementing a %packages in ks.cfg-style parser as a yum-util shouldn't be much work. Mostly just extracting the code from anaconda, I'd bet.
-sv
On Thu, 2006-09-21 at 00:31 +0200, Chitlesh GOORAH wrote:
Ill try pilgrim this weekend.
Thanks!
The first step towards that, and something I'd like anyway, is moving the pilgrim git repository from my home directory on freedesktop.org to Fedora infrastructure. Any pointers to how I do that? Thanks.
is it possible to have under svn ? :p i've cvs access blocked over my place.
Oh, I'm suggesting to use git. That, AFAIK, can be tunneled over ssh which shouldn't be a problem from your place? (I think it can also be tunneled over http, not sure.)
David, is your presentations available for download ? I'll like to have a look at them :)
Presentations? Do you mean the ISO, that one is here
http://olpc.download.redhat.com/olpc/fedora-desktop-davidz-stream-developmen...
or anything else?
Cheers, David
On 9/20/06, Greg DeKoenigsberg gdk@redhat.com wrote:
These three facts, in my mind, are reason enough to ask the Fedora Live CD community to consider the benefits of Pilgrim. If we want to develop the two technologies side-by-side, that's fine too. But this is the fedora-livecd-list -- *not* the kadischi list.
This was the main reason why I've asked Fedora Board to ping David for more info about pilgrim in this list ! :)
Chitlesh
desktop@lists.fedoraproject.org
-
Bill Nottingham -
Chitlesh GOORAH -
Dan Williams -
David Zeuthen -
Gain Paolo Mureddu -
Greg DeKoenigsberg -
Rahul Sundaram -
seth vidal