[Fedora-livecd-list] mandatory syslinux on live cd causes perl dependency

[Mads Kiilerich]

On 03/04/2010 11:49 AM, Marc Herbert wrote:
> Hi Mads,
>
>> Livecd-creator is executed on the host system and creates isolinux.cfg
>> (syslinux.cfg) by its own logic and hardcoded templates. It also runs
>> isohybrid if available, and the hosts livecd-iso-to-disk runs syslinux.
>> I don't see any reason why livecd-creator should use vesamenu.c32 and
>> isolinux.bin from the installed image.
>
> Because it makes sure they are available and from a well defined
> version?

Good point. But they still they are referenced from a boot loader 
installation and syslinux.cfg and which doesn't come from a well defined 
version.

> I think a bootloader is generally supposed to "belong" to the system it
> boots. People say that they have installed "Fedora 16", not "Fedora 16
> and GRUB 3.14".

On the other side: The bootloader is a meta thing which only for 
convenience is so deeply and seamlessly integrated with Fedora. That is 
also why a image unaware of syslinux can be booted with syslinux, even 
though some packages (kernels/dracut/plymouth) does a (IMHO) hackish but 
efficient "layering violation" and assumes that grub is used.

Looks like you are suggesting to make the liveCD even
> more an exception to this rule than it already is. Is this the right
> design choice? I honestly do not know.  If it made sense I would prefer
> going all the opposite way and depend as little as possible from the
> software of the (unknown) build system.

Right now there _is_ an exception, and I think it should be a primary 
goal here to make it more consistent - with or without an exception.

livecd-creator itself _is_ an exception. Using a different version of 
livecd-creator can make a huge difference to the created image. 
(livecd-creator has however been very stable recently - stable in the 
sense that it works fine and there hasn't been much new development.)

A consequence of what you propose would be to install livecd-creator 
(and anaconda?) in the image and let it do all the hard work with 
applying the kickstart configuration and installing the boot loader. 
Obviously the build system would have to bootstrap it, probably mostly 
by taking care of the %package section.

I guess that could work, but I think it is unfortunate to put even more 
dependencies into the live image. I would rather focus on making sure 
that the live image only contains what is need on runtime.

>> Using files from different unrelated packages even has the risk of
>> causing problems whenever the feature-set changes.
>
> Could you elaborate on this?

What I meant was that with the content of syslinux.cfg coming from 
livecd-creator in the build system and vesamenu.c32 and isolinux.bin 
from the installed image then they can come out of sync, and it will be 
hard to ever make changes to either of them.

>> I think the best solution is to drop the hardcoded dependency to
>> syslinux and use the files from the host system.
>
> Then a new "syslinux-data" RPM would still be useful - now to the build
> system.

IMHO the dependency chain isn't that big a problem on the build system, 
and more important: The build system will (in most cases) need 
"syslinux-executables" anyway.

I'm not sure that splitting syslinux up to allow mixing independent 
parts is an good idea.

> FYI: my build system tends to be automatically kickstarted to avoid the
> concerns I mentioned above.

I can see how that can be a good idea - assuming that you have a stable 
local yum mirror.

/Mads