Closed kgilmer closed 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.
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
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.
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!
Closing since we agreed on a strategy and implementation is proceeding.
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:
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.
For example: build.sh
configure.sh
Pros: fairly simple, only changes to script are string literals. Cons: More scripts to run, possibly difficult to get the process fool proof.
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
build.sh
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.