Hi jnqnfe
>1) What exactly is the use case for [...]
I don't know if its my poor english maybe, but i don't reaally know what
you mean by that. Can you explan a bit more?
Relating to point 2:
I think that some real life use example of that that just came to my
head is providing script that would override the binary of make command
with colormake (when you also choose apt option to not download binary
packages but sources and compile them to build a chroot filesystem) to
see beautiful color output to follow looking for possible errors. Or
another one to use multistrap somehow as a boostrap binary which is not
normally supported by live-build script. So maybe the code should be
changed simply to not to ignore that value and make us of that option at
any stage? And maybe some simple config to specify in which stages it
should be used?
>So is this actually needed?
I would say. Yes. Even for me. I think I would like to use this in the
future to have more possibility's of building very specific live image.
But it also depends on doing a lot of research before to expand my
knowledge a bit.
I wanted to share my opinion because I am in the middle of process to
build my perfect out-of-box image for my hardware and any change in
live-build probably will change a bit my concept. Which is also possible:D
hmmm...yeah
jnqnfe:
> I have a few questions I'd like to put out to you all (perhaps Daniel in
> particular) in relation to some restructuring work I'm doing on the
> live-build codebase (a contribution for which I know I haven't yet
> provided much detail on what exactly I'm changing, but I will do soon,
> and will obviously be subject to Daniel's approval if its to be adopted).
>
> So the questions:
>
> 1) What exactly is the use case for a user running live-build with a
> copy of the utility's code within their build directory? Does anyone
> actually do this rather than running an installed copy? If so why? I
> don't know why the codebase bothers to offer such support.
>
> I can see in binary_syslinux that the local config may provide the
> bootloader as an alternative to the /usr/share copy through this
> directory structure, but that can be supported without this. Similarly
> with the bin/Packages script file.
>
> 2) The point of the local/bin directory of your build directory is what?
> It's created by the config script, and then used in constructing a PATH
> variable in the common.sh functions script
> (PATH=${PWD}/local/bin/:{$PATH}), but the only place I see the PATH
> variable is used is in the chroot.sh functions script, which seems to
> ignore this since it's being set to a hard coded value when used there.
> A version 3.x changelog entry describes it as "for executables
> overriding not just lb scripts, but any command during live-build runs".
>
> So is this actually needed? Is the described functionality really
> actually needed pretending this actually did what it's supposed to
> allow? Or is it just dead code awaiting removal, like the
> source_debian-live script (which seems to have been left over from a
> renaming to the source_live script)?
>
> 3) File locations. Why is /usr/lib/live/build.sh located there and not
> in the build directory, and while I can perhaps understand copies of
> bootloaders being in /usr/share/live/build, what about most of the rest
> such as functions, why are these here under share instead of lib?
Attachment:
signature.asc
Description: OpenPGP digital signature