mvallim / live-custom-ubuntu-from-scratch

(Yes, the project is still alive 😃) This procedure shows how to create a bootable and installable Ubuntu Live (along with the automatic hardware detection and configuration) from scratch.
https://mvallim.github.io/live-custom-ubuntu-from-scratch/
GNU General Public License v3.0
397 stars 186 forks source link

Allow customization without fork #23

Closed kgilmer closed 3 years ago

kgilmer commented 3 years ago

Is your feature request related to a problem? Please describe. The existing scripts hard code some string constants that most users will likely change to meet their needs. For example the name of the ISO or the GRUB entries.

If I make changes to the scripts however, it becomes more difficult to merge upstream changes/fixes as I have made changes myself.

Ideally I could specify all the parameters I need to generate my ISO without having to fork this repo.

Describe the solution you'd like There are a few strategies that could be used here:

  1. Express each customization as a command line parameter to the build.sh script.

Pros: common way for scripts to get custom params Cons: maybe many parameters would be needed, will make the script more difficult to use, passing these params across scripts, parameter number or order changing breaks older versions.

  1. Express each customization as a search/replace operation. In this case there would be a property file specifying values, and a script that would simply search/replace in the shell scripts to substitute the actual values.

For example: build.sh

...
menuentry "%%GRUB_LIVEBOOT_LABEL%%" {
   linux /casper/vmlinuz boot=casper nopersistent toram quiet splash ---
   initrd /casper/initrd
}

configure.sh

GRUB_LIVEBOOT_LABEL=somethingsomething

sed -i 's/%%GRUB_LIVEBOOT_LABEL%%/$GRUB_LIVEBOOT_LABEL/g' build.sh > build2.sh

Pros: fairly simple, only changes to script are string literals. Cons: More scripts to run, possibly difficult to get the process fool proof.

  1. Look for a file, say configuration.sh in the same directory, if present source the script. Use well known variables that would be defined for each parameter.

Example:

configuration.sh

GRUB_LIVEBOOT_LABEL=somethingsomething

build.sh

...
if [ -f ./configuration.sh ]; then 
  source configuration.sh
fi
...
menuentry "$GRUB_LIVEBOOT_LABEL" {
...

pros: no mutation of script files, fairly simple cons: requires all config to be expressed as variables, must have defaults in script?

I have not tested any of these approaches and of course there may be other ways too. @mvallim any thoughts here? Do you care about this sort of thing, or you'd just prefer people to fork and change their scripts as needed?

Describe alternatives you've considered Likely I will go with option 3 and swap out string literals for variables and have a top level configuration script that defines each value.

Additional context Add any other context or screenshots about the feature request here.

kgilmer commented 3 years ago

To be clear, I'm willing to submit a PR with changes if this is something the project maintainers are interested in.

mvallim commented 3 years ago

Hi @kgilmer,

Thank you for your contribution.

@mvallim any thoughts here?

The 3th approach seems to be the best in the sense of enabling customizations in a simpler way without changing the core in the generation of the iso image.

Do you care about this sort of thing, or you'd just prefer people to fork and change their scripts as needed?

Yes, I am concerned that the simpler to use and the less customization in the ad-hoc scripts... better!

I implemented this feature, as described and it proved to be very good. https://github.com/mvallim/live-custom-ubuntu-from-scratch/pull/24

Would you be able to add in the tutorial of the scripts how to use it? (README.md)

Thank you very much, @mvallim

kgilmer commented 3 years ago

Fantastic! Yes, I am happy to update the documentation to describe usage. If you're good with this strategy then we can add other parameters to configuration.sh such as ISO filename, package list to remove, package list to add, etc.

mvallim commented 3 years ago

Fantastic! Yes, I am happy to update the documentation to describe usage. If you're good with this strategy then we can add other parameters to configuration.sh such as ISO filename, package list to remove, package list to add, etc.

Perfect!

We can do everything! Sounds pretty good!

kgilmer commented 3 years ago

Closing since we agreed on a strategy and implementation is proceeding.