1:40 p.m.
A patch which allows multiple kernels to be installed on the live media,
giving boot options in the syslinux menu for all of them.
In addition, this patch adds an optional timeout parameter for the boot
menu. It also adds a cli parameter for appending boot options.
Kind regards,
Jeroen van Meeuwen
-kanarip
2:03 p.m.
Jeroen van Meeuwen wrote:
A patch which allows multiple kernels to be installed on the live
media,
giving boot options in the syslinux menu for all of them.
In addition, this patch adds an optional timeout parameter for the boot
menu. It also adds a cli parameter for appending boot options.
My bad, I had left some old code in there before I created the patch.
Hopefully this looks better.
Kind regards,
Jeroen van Meeuwen
-kanarip
2:19 p.m.
Jeroen van Meeuwen wrote:
Jeroen van Meeuwen wrote:
> A patch which allows multiple kernels to be installed on the live media,
> giving boot options in the syslinux menu for all of them.
>
> In addition, this patch adds an optional timeout parameter for the boot
> menu. It also adds a cli parameter for appending boot options.
>
My bad, I had left some old code in there before I created the patch.
Hopefully this looks better.
Grmbl, it needs to import re too... Seems I need more coffee
4:07 p.m.
On Sun, 2007-08-05 at 20:40 +0200, Jeroen van Meeuwen wrote:
A patch which allows multiple kernels to be installed on the live
media,
giving boot options in the syslinux menu for all of them.
This part looks mostly reasonable...
In addition, this patch adds an optional timeout parameter for the
boot
menu. It also adds a cli parameter for appending boot options.
I think a better approach for this, though, is to extend the kickstart
bootloader syntax a little bit. The proliferation of command-line
options for this is a little ridiculous. Also, it leads to the images
not being reproducible just from the kickstart config
Jeremy
4:59 p.m.
Jeremy Katz wrote:
On Sun, 2007-08-05 at 20:40 +0200, Jeroen van Meeuwen wrote:
> A patch which allows multiple kernels to be installed on the live media,
> giving boot options in the syslinux menu for all of them.
This part looks mostly reasonable...
> In addition, this patch adds an optional timeout parameter for the boot
> menu. It also adds a cli parameter for appending boot options.
I think a better approach for this, though, is to extend the kickstart
bootloader syntax a little bit. The proliferation of command-line
options for this is a little ridiculous. Also, it leads to the images
not being reproducible just from the kickstart config
It's never reproducible from kickstart config as kickstart is not
allowing you to set specific version numbers, nor filesystem
compression, prelinking, ignoring deleted files, etc.
I'd rather have some error, bug or dis-functionality that I can fix. I
can't read your mind and think of the better approach without seeing the
code live in some upstream source repository. If it's reasonable, like
the previous patch, you get to apply it and _then_ think of a better
way, then apply that. Just a cloud of better ideas doesn't make it rain.
Kind regards,
Jeroen van Meeuwen
-kanarip
5:29 p.m.
Jeroen van Meeuwen wrote:
Jeremy Katz wrote:
> On Sun, 2007-08-05 at 20:40 +0200, Jeroen van Meeuwen wrote:
>> A patch which allows multiple kernels to be installed on the live media,
>> giving boot options in the syslinux menu for all of them.
> This part looks mostly reasonable...
>
>> In addition, this patch adds an optional timeout parameter for the boot
>> menu. It also adds a cli parameter for appending boot options.
> I think a better approach for this, though, is to extend the kickstart
> bootloader syntax a little bit. The proliferation of command-line
> options for this is a little ridiculous. Also, it leads to the images
> not being reproducible just from the kickstart config
>
It's never reproducible from kickstart config as kickstart is not
allowing you to set specific version numbers, nor filesystem
compression, prelinking, ignoring deleted files, etc.
I agree with this point... and how it relates to my prior addidir/addsdir
patch... *But*...
I'd rather have some error, bug or dis-functionality that I can fix. I
can't read your mind and think of the better approach without seeing the
code live in some upstream source repository. If it's reasonable, like
the previous patch, you get to apply it and _then_ think of a better
way, then apply that. Just a cloud of better ideas doesn't make it rain.
I think your arguments Jeroen would be more valid if you had a little more
patience. I.e. I don't remember seeing much design-debate over the current
contentious issues. And it's only been a couple days since you posted the
patch. *And* revisor appears to already be working off of its own copy of
pilgrim.py (as I figured out when I wondered why the patches were still using
that name).
Thus I don't think there is any reason to rush this particular debate. By
posting the initial ideas, and getting initial feedback from the list, _and then
waiting a few days/weeks_ someone might figure out a drastically more elegant
solution. Or not.
Now, if a couple months go by, and neither my turboLiveInst patch nor anything
better, nor any ability to easily replicate the ubuntu feature of throwing extra
goodies in the iso
(e.g. firefox windows installer, autorun.bat+why_f8livecdkicksass.html)
then maybe I'll take up your side of the argument.
-dmc
5:36 p.m.
Douglas McClendon wrote:
I think your arguments Jeroen would be more valid if you had a
little
more patience.
Believe me, this has been going on for quite a while.
I.e. I don't remember seeing much design-debate over
the current contentious issues. And it's only been a couple days
since
you posted the patch. *And* revisor appears to already be working off
of its own copy of pilgrim.py (as I figured out when I wondered why the
patches were still using that name).
Right, that pilgrim.py is getting us ugly faces everywhere. Working with
us is a matter of principle for these guys. All we need is the '-' to
be removed from the 'livecd-creator' command.
Kind regards,
Jeroen van Meeuwen
-kanarip
5:47 p.m.
Jeroen van Meeuwen wrote:
Douglas McClendon wrote:
> I think your arguments Jeroen would be more valid if you had a little
> more patience.
Believe me, this has been going on for quite a while.
I've been on this list for years (jdogalt). Believe me, I've got my own litany
of issues.
But from where I'm standing, it does look like you threw up 6 patches without
much obvious design discussion beforehand, and you are getting too upset too
quickly.
Since the livecd-creator bits are what is used to build the official fedora
releases, I do think there should be a fair amount of resistence to changes.
I.e. I don't remember seeing much design-debate over
> the current contentious issues. And it's only been a couple days since
> you posted the patch. *And* revisor appears to already be working off
> of its own copy of pilgrim.py (as I figured out when I wondered why the
> patches were still using that name).
Right, that pilgrim.py is getting us ugly faces everywhere. Working with
us is a matter of principle for these guys. All we need is the '-' to
be removed from the 'livecd-creator' command.
Can you explain this a bit more? I am not a seasoned python programmer, but
that sounds like a _really_ strange issue to me???
-dmc
7:04 p.m.
On Mon, 2007-08-06 at 17:47 -0500, Douglas McClendon wrote:
Jeroen van Meeuwen wrote:
> Douglas McClendon wrote:
>> I think your arguments Jeroen would be more valid if you had a little
>> more patience.
>
> Believe me, this has been going on for quite a while.
I've been on this list for years (jdogalt). Believe me, I've got my own litany
of issues.
But from where I'm standing, it does look like you threw up 6 patches without
much obvious design discussion beforehand, and you are getting too upset too
quickly.
Since the livecd-creator bits are what is used to build the official fedora
releases, I do think there should be a fair amount of resistence to changes.
I'm not at all against resistance to changes that might not be quite
ready. I am against hindering innovation, in any form, or minimally
causing discouragement because we have taken on code that helps us do
what what want to do with software, even when upstream is not ready for
us to. :-D
>
> I.e. I don't remember seeing much design-debate over
>> the current contentious issues. And it's only been a couple days since
>> you posted the patch. *And* revisor appears to already be working off
>> of its own copy of pilgrim.py (as I figured out when I wondered why the
>> patches were still using that name).
>
> Right, that pilgrim.py is getting us ugly faces everywhere. Working with
> us is a matter of principle for these guys. All we need is the '-' to
> be removed from the 'livecd-creator' command.
Can you explain this a bit more? I am not a seasoned python programmer, but
that sounds like a _really_ strange issue to me???
It's a matter of livecd-creator not wanting to be imported and
subclassed. Ignore that the sys.path.append() is more then nasty, but it
does help to illustrate discussion we have had in the past around the
time of the Fedora 7 release. The revisor team has wanted the livecd
bits to be importable (in a similar way that pungi has allowed us to)
and when that was denied we had to make the controversial decision to
pull the full source into revisor. My understanding, at least this is
what I took from the discussion, is that livecd-creator is just not
ready to be imported and is offering nothing resembling a stable
API/code base. This didn't bother us at all, we were willing to fix any
issue that arises from changes in livecd-creator and the way we utilized
the code in revisor. To just move on and start getting things done, we
brought all of livecd-creator into revisor and named it pilgrim.py. When
we move to do a release we try our best to rebase and then submit our
changes upstream, hoping to help mature the API/code base far along
enough where we are allowed to import and utilize it.
Consider the following:
>> import sys
>> sys.path.append('/usr/bin')
>> import livecd-creator
File "<stdin>", line 1
import livecd-creator
^
SyntaxError: invalid syntax
>>
Now, without the dash:
Yuck: [ ln -s /usr/bin/livecd-creator /usr/bin/livecdcreator.py ]
>>> import sys
>>> sys.path.append('/usr/bin')
>>> import livecdcreator
>>
You could then continue on with:
>> myubercoolliveimage =
livecdcreator.InstallationTarget(options.more,
options.yeah)
At this point you have access to the needed toolchain with your
'myubercoolliveimage' and also allows us (revisor team) to make our
changes much more gracefully by subclassing or overriding functions
almost as a proof of concept. Forgive my rudimentary example, but most
of the reason why we have just brought all of livecd-tools into revisor
is to not waste a *ton* of time on discussions just like this one. I'm
not saying I don't find value in this type of good, open debate... it is
more I personally work better expressing what I would like to see
software do by at least getting some sort of code down. Some of the
things we are doing in revisor might seem elementary and, also,
underdeveloped but we are trying to work out a feature rich application
that has both a fully functional CLI and GUI mode that puts an amazing
amount of power right at the end users hands. I'm trying to not fuel the
fire here as we all have much more productive things we can be working
on. ;-)
Jonathan Steffan
daMaestro
12:05 a.m.
Jonathan Steffan wrote:
On Mon, 2007-08-06 at 17:47 -0500, Douglas McClendon wrote:
> Jeroen van Meeuwen wrote:
>> Douglas McClendon wrote:
>>> I think your arguments Jeroen would be more valid if you had a little
>>> more patience.
>> Believe me, this has been going on for quite a while.
> I've been on this list for years (jdogalt). Believe me, I've got my own
litany
> of issues.
>
> But from where I'm standing, it does look like you threw up 6 patches without
> much obvious design discussion beforehand, and you are getting too upset too
> quickly.
>
> Since the livecd-creator bits are what is used to build the official fedora
> releases, I do think there should be a fair amount of resistence to changes.
I'm not at all against resistance to changes that might not be quite
ready. I am against hindering innovation, in any form, or minimally
causing discouragement because we have taken on code that helps us do
what what want to do with software, even when upstream is not ready for
us to. :-D
It's a subtle thing, but I would take the lack of upstream merging as an
absence of encouragement, and not the presence of discouragement.
>> I.e. I don't remember seeing much design-debate over
>>> the current contentious issues. And it's only been a couple days since
>>> you posted the patch. *And* revisor appears to already be working off
>>> of its own copy of pilgrim.py (as I figured out when I wondered why the
>>> patches were still using that name).
>> Right, that pilgrim.py is getting us ugly faces everywhere. Working with
>> us is a matter of principle for these guys. All we need is the '-' to
>> be removed from the 'livecd-creator' command.
> Can you explain this a bit more? I am not a seasoned python programmer, but
> that sounds like a _really_ strange issue to me???
It's a matter of livecd-creator not wanting to be imported and
subclassed. Ignore that the sys.path.append() is more then nasty, but it
does help to illustrate discussion we have had in the past around the
time of the Fedora 7 release. The revisor team has wanted the livecd
bits to be importable (in a similar way that pungi has allowed us to)
and when that was denied we had to make the controversial decision to
pull the full source into revisor. My understanding, at least this is
what I took from the discussion, is that livecd-creator is just not
ready to be imported and is offering nothing resembling a stable
API/code base. This didn't bother us at all, we were willing to fix any
issue that arises from changes in livecd-creator and the way we utilized
the code in revisor. To just move on and start getting things done, we
brought all of livecd-creator into revisor and named it pilgrim.py. When
we move to do a release we try our best to rebase and then submit our
changes upstream, hoping to help mature the API/code base far along
enough where we are allowed to import and utilize it.
It sounds like this is a perfect example of when forking works.
Consider the following:
>>> import sys
>>> sys.path.append('/usr/bin')
>>> import livecd-creator
File "<stdin>", line 1
import livecd-creator
^
SyntaxError: invalid syntax
Now, without the dash:
Yuck: [ ln -s /usr/bin/livecd-creator /usr/bin/livecdcreator.py ]
ln -s /usr/bin/livecd-creator /usr/lib/livecd-creator/livecdcreator.py
would be quite a bit less yucky.
>>> import sys
>>> sys.path.append('/usr/bin')
>>> import livecdcreator
>>>
You could then continue on with:
>>> myubercoolliveimage = livecdcreator.InstallationTarget(options.more,
options.yeah)
At this point you have access to the needed toolchain with your
'myubercoolliveimage' and also allows us (revisor team) to make our
changes much more gracefully by subclassing or overriding functions
almost as a proof of concept. Forgive my rudimentary example, but most
of the reason why we have just brought all of livecd-tools into revisor
is to not waste a *ton* of time on discussions just like this one. I'm
not saying I don't find value in this type of good, open debate... it is
more I personally work better expressing what I would like to see
software do by at least getting some sort of code down. Some of the
things we are doing in revisor might seem elementary and, also,
underdeveloped but we are trying to work out a feature rich application
that has both a fully functional CLI and GUI mode that puts an amazing
amount of power right at the end users hands. I'm trying to not fuel the
fire here as we all have much more productive things we can be working
on. ;-)
+1 for forking. Personally I'm sitting on a few thousand lines of bash
code that duplicates the functionality of livecd-creator myself (they
just run about 6 times slower, but have a few beneficial aspects that I
think may eventually be worthwhile for a larger audience).
I'm quite optimistic that 2 years from now, fedora will have (at least
one) really excellent livecd generation program, which uses great
features pioneered by everyone on this list.
To quote some of the last lines of perhaps my favorite rock opera-
"we can walk our road together,
if our goals are all the same.
we can run alone and free,
if we pursue a different aim."
-dmc
3 a.m.
On Tue, 2007-08-07 at 00:05 -0500, Douglas McClendon wrote:
Jonathan Steffan wrote:
> On Mon, 2007-08-06 at 17:47 -0500, Douglas McClendon wrote:
>> Jeroen van Meeuwen wrote:
>>> Douglas McClendon wrote:
[...]
>>> I.e. I don't remember seeing much design-debate
over
>>>> the current contentious issues. And it's only been a couple days
since
>>>> you posted the patch. *And* revisor appears to already be working off
>>>> of its own copy of pilgrim.py (as I figured out when I wondered why the
>>>> patches were still using that name).
>>> Right, that pilgrim.py is getting us ugly faces everywhere. Working with
>>> us is a matter of principle for these guys. All we need is the '-'
to
>>> be removed from the 'livecd-creator' command.
>> Can you explain this a bit more? I am not a seasoned python programmer, but
>> that sounds like a _really_ strange issue to me???
>
>
[...]
>
It sounds like this is a perfect example of when forking works.
>
> Consider the following:
>
>>>> import sys
>>>> sys.path.append('/usr/bin')
>>>> import livecd-creator
> File "<stdin>", line 1
> import livecd-creator
> ^
> SyntaxError: invalid syntax
>
> Now, without the dash:
>
> Yuck: [ ln -s /usr/bin/livecd-creator /usr/bin/livecdcreator.py ]
ln -s /usr/bin/livecd-creator /usr/lib/livecd-creator/livecdcreator.py
would be quite a bit less yucky.
Yes. ;-)
It is still a nasty workaround to require your software to setup a
symlink just to import code. We did look at this option, I just wanted
to bring up that we had evaluated it.
[...]
+1 for forking. Personally I'm sitting on a few thousand lines of bash
code that duplicates the functionality of livecd-creator myself (they
just run about 6 times slower, but have a few beneficial aspects that I
think may eventually be worthwhile for a larger audience).
We are in no way against working with upstream to make sure forward
progress is made so everyone gains.
I'm quite optimistic that 2 years from now, fedora will have (at least
one) really excellent livecd generation program, which uses great
features pioneered by everyone on this list.
I'm more then optimistic we will have an amazing provisioning system,
including live/stateless media, for Fedora 9 if not for Fedora 8 ;-)
To quote some of the last lines of perhaps my favorite rock opera-
"we can walk our road together,
if our goals are all the same.
we can run alone and free,
if we pursue a different aim."
Awesome quote.
Jonathan Steffan
daMaestro
4:10 p.m.
On Mon, 2007-08-06 at 18:04 -0600, Jonathan Steffan wrote:
It's a matter of livecd-creator not wanting to be imported and
subclassed. Ignore that the sys.path.append() is more then nasty, but it
does help to illustrate discussion we have had in the past around the
time of the Fedora 7 release. The revisor team has wanted the livecd
bits to be importable (in a similar way that pungi has allowed us to)
and when that was denied we had to make the controversial decision to
pull the full source into revisor. My understanding, at least this is
what I took from the discussion, is that livecd-creator is just not
ready to be imported and is offering nothing resembling a stable
API/code base. This didn't bother us at all, we were willing to fix any
issue that arises from changes in livecd-creator and the way we utilized
the code in revisor.
I know that you guys don't mind. But the problem is that once it's
installed, it's open season for anyone else who might want to depend on
it also. And it happens. Trust me. There are some bits that snuck
into rhpl to be "only" used by anaconda and firstboot, yet have ended up
in all kinds of other places. Making it a lot harder to change them,
fix them or otherwise improve them. So really, the fact that we're not
guaranteeing any sort of API is just what lets us continue to _make_
large changes, some of which you've proposed and other that have been by
others[1]. If this were all C, then interface versioning is doable and
not that painful... being python, a lot of that functionality doesn't
exist
Douglas's idea of doing a symlink if you really want to import now is
one of the best I've seen and I don't know why I didn't think about it
when we had this discussion months ago.
Jeremy
[1] On my todo list for pre-test2 that will impact the internal API of
livecd-creator is getting the patches from dwmw2/spot merged for ppc and
sparc. And if there's time, I do want to get back to markmc's "image
abstraction" patches as I know there's a fair bit of desire around them
as well.
4:03 p.m.
On Mon, 2007-08-06 at 23:59 +0200, Jeroen van Meeuwen wrote:
Jeremy Katz wrote:
> On Sun, 2007-08-05 at 20:40 +0200, Jeroen van Meeuwen wrote:
>> A patch which allows multiple kernels to be installed on the live media,
>> giving boot options in the syslinux menu for all of them.
>
> This part looks mostly reasonable...
>
>> In addition, this patch adds an optional timeout parameter for the boot
>> menu. It also adds a cli parameter for appending boot options.
>
> I think a better approach for this, though, is to extend the kickstart
> bootloader syntax a little bit. The proliferation of command-line
> options for this is a little ridiculous. Also, it leads to the images
> not being reproducible just from the kickstart config
It's never reproducible from kickstart config as kickstart is not
allowing you to set specific version numbers, nor filesystem
compression, prelinking, ignoring deleted files, etc.
Version numbers should be able to be specified if you want that level of
reproducibility. Filesystem compression/ignoring deleted files are
largely developer options for convenience and not something which (in my
mind at least) should be a part of a "production" image. Adding the
prelinking option was, in retrospect, something of a mistake and should
either have been done by extending kickstart or just using the %post.
I actually want to sit down and do some clean-up of the options to sort
of "hide" the developer only options and try to make it more obvious
that the kickstart config is the way to go
I'd rather have some error, bug or dis-functionality that I can
fix. I
can't read your mind and think of the better approach without seeing the
code live in some upstream source repository. If it's reasonable, like
the previous patch, you get to apply it and _then_ think of a better
way, then apply that. Just a cloud of better ideas doesn't make it rain.
No, you get feedback to the patch saying "maybe try this way instead"
and that can point you down a path that's cleaner. It doesn't have to
be in the upstream repo to get feedback and act on it. Maybe I wasn't
clear enough in what I was suggesting, so I'll try to flesh it out a
little more.
Rather than command line options for the timeout, preferred kernel and
bootloader options, we should probably use the existing kickstart
"bootloader" stanza and extend it a bit. It already has an option to
specify additional kernel options ("--append") which we can use. And
then it would make sense to also have it take a --timeout and
--defaultkernel (or similar) option. This will let us parse the info
from the config rather than from the command line and carrying things
around
Ultimately, we'll want this in pykickstart itself, but we could start
with a subclass of the KickstartParser with a custom KickstartHandler
for the bootloader command. Just the patch to pykickstart is likely to
be simpler, though. And having the livecd-creator patch depend on the
pykickstart change is okay
Jeremy
6116
days inactive
6118
days old
livecd@lists.fedoraproject.org
13 comments
4 participants
participants (4)
-
Douglas McClendon -
Jeremy Katz -
Jeroen van Meeuwen -
Jonathan Steffan