Merge lp://staging/~mabac/linaro-image-tools/scripts-hooks into lp://staging/linaro-image-tools/11.11

Tested with 2 simple scripts and it worked well.

A few comments:
1. At the preinstall script there's no way to access the hwpack content, because it wasn't yet extracted. This may be useful for people that want to read from hwpack packages or even customize in some way.
2. Would be useful if we could also copy both scripts at the rootfs, as it might help debugging any issues in the future.
3. Would also be useful if we could stamp that the image was customized by a script, like by adding a message via /etc/update-motd.d, so it'd show that info to the user.

Hi,

Do we need the extra command line options? I'm thinking about a hook dir where you drop your hooks, in the same way it's done on live-build [1] or pbuilder[2]. A prefix will determine at which stage the scripts will be used. Until the proper solution is implemented, you can hardcode the scripts name.

[1] /usr/share/live/build/examples/hooks
[2] /usr/share/doc/pbuilder/examples

> 2. Would be useful if we could also copy both scripts at the rootfs
> 3. Would also be useful if we could stamp that the image was customized by a script

for both, I'll leave these outside of l-m-c. It's up to the developer and could be done through the hooks.

> Tested with 2 simple scripts and it worked well.
>
> A few comments:
> 1. At the preinstall script there's no way to access the hwpack content,
> because it wasn't yet extracted. This may be useful for people that want to
> read from hwpack packages or even customize in some way.

Would you like the pre-hooks to be run in linaro-hwpack-install instead? That way the script can be run for every hwpack after unpacking it, meaning the pre-hook is run once per hwpack. If you mean we should unpack all the hwpacks and then run the pre-hook once it will require some more work but it is possible of course.

> 2. Would be useful if we could also copy both scripts at the rootfs, as it
> might help debugging any issues in the future.
> 3. Would also be useful if we could stamp that the image was customized by a
> script, like by adding a message via /etc/update-motd.d, so it'd show that
> info to the user.

> Hi,
>
> Do we need the extra command line options? I'm thinking about a hook dir where

It's all down to how you'd like this to behave, we can do that instead. I think the discussions on irc kept mentioning command line options which is why I did that. Any other opinions about cli options vs a hook dir?

> you drop your hooks, in the same way it's done on live-build [1] or
> pbuilder[2]. A prefix will determine at which stage the scripts will be used.
> Until the proper solution is implemented, you can hardcode the scripts name.
>
> [1] /usr/share/live/build/examples/hooks
> [2] /usr/share/doc/pbuilder/examples
>
> > 2. Would be useful if we could also copy both scripts at the rootfs
> > 3. Would also be useful if we could stamp that the image was customized by a
> script
>
> for both, I'll leave these outside of l-m-c. It's up to the developer and
> could be done through the hooks.

I think it can be settled by sorting out if this always will be needed or if there may be cases where the hook author would want no trace of the hooks on the target system. If we feel that we need this for helping people with messed up images we need to do it in l-m-c. If it's up to the developer, I'm happy to leave this bit out.

On Wed, Jan 25, 2012 at 6:35 AM, Mattias Backman
<email address hidden> wrote:
>> Tested with 2 simple scripts and it worked well.
>>
>> A few comments:
>> 1. At the preinstall script there's no way to access the hwpack content,
>> because it wasn't yet extracted. This may be useful for people that want to
>> read from hwpack packages or even customize in some way.
>
> Would you like the pre-hooks to be run in linaro-hwpack-install instead? That way the script can be run for every hwpack after unpacking it, meaning the pre-hook is run once per hwpack. If you mean we should unpack all the hwpacks and then run the pre-hook once it will require some more work but it is possible of course.

Can you flash the image using more than one hwpack? I thought it'd use
just one hwpack :-)

Guess to simplify things having the pre-hook the way you implemented
should be fine for now.

On Wed, Jan 25, 2012 at 6:42 AM, Mattias Backman
<email address hidden> wrote:
>> Hi,
>>
>> Do we need the extra command line options? I'm thinking about a hook dir where
>
> It's all down to how you'd like this to behave, we can do that instead. I think the discussions on irc kept mentioning command line options which is why I did that. Any other opinions about cli options vs a hook dir?

While I like the pbuilder/livebuild way of hooking the script, I think
having them as a parameter (for pre/post) is more than enough, besides
easier to implement. If the user really want to customize the image
this much, I'd prefer him to go and create his own image by running
live-build by hand.

>> > 2. Would be useful if we could also copy both scripts at the rootfs
>> > 3. Would also be useful if we could stamp that the image was customized by a
>> script
>>
>> for both, I'll leave these outside of l-m-c. It's up to the developer and
>> could be done through the hooks.
>
> I think it can be settled by sorting out if this always will be needed or if there may be cases where the hook author would want no trace of the hooks on the target system. If we feel that we need this for helping people with messed up images we need to do it in l-m-c. If it's up to the developer, I'm happy to leave this bit out.

Do we have the logs from the l-m-c available at the image already?
Guess that this would be enough already.

> On Wed, Jan 25, 2012 at 6:42 AM, Mattias Backman
> <email address hidden> wrote:
> >> Hi,
> >>
> >> Do we need the extra command line options? I'm thinking about a hook dir
> where
> >
> > It's all down to how you'd like this to behave, we can do that instead. I
> think the discussions on irc kept mentioning command line options which is why
> I did that. Any other opinions about cli options vs a hook dir?
>
> While I like the pbuilder/livebuild way of hooking the script, I think
> having them as a parameter (for pre/post) is more than enough, besides
> easier to implement. If the user really want to customize the image
> this much, I'd prefer him to go and create his own image by running
> live-build by hand.

I see at least one argument to prefer linaro-media-create instead of live-build for the job: it will work on other distributions. afaik, live-build isn't available on something else than Debian/Ubuntu, more over we carry a modified version available in our PPA.

> >> > 2. Would be useful if we could also copy both scripts at the rootfs
> >> > 3. Would also be useful if we could stamp that the image was customized
> by a
> >> script
> >>
> >> for both, I'll leave these outside of l-m-c. It's up to the developer and
> >> could be done through the hooks.
> >
> > I think it can be settled by sorting out if this always will be needed or if
> there may be cases where the hook author would want no trace of the hooks on
> the target system. If we feel that we need this for helping people with messed
> up images we need to do it in l-m-c. If it's up to the developer, I'm happy to
> leave this bit out.

As a hook author, I don't want trace of the hooks as I want to keep it small :)

> Do we have the logs from the l-m-c available at the image already?
> Guess that this would be enough already.

Do you mean a build log shipped inside the image? We don't have that.
We can add traces on l-m-c build log (though, it isn't shipped in the generated rootfs).

On Wed, Jan 25, 2012 at 4:08 PM, Fathi Boudra <email address hidden> wrote:
>> On Wed, Jan 25, 2012 at 6:42 AM, Mattias Backman
>> <email address hidden> wrote:
>> >> Hi,
>> >>
>> >> Do we need the extra command line options? I'm thinking about a hook dir
>> where
>> >
>> > It's all down to how you'd like this to behave, we can do that instead. I
>> think the discussions on irc kept mentioning command line options which is why
>> I did that. Any other opinions about cli options vs a hook dir?
>>
>> While I like the pbuilder/livebuild way of hooking the script, I think
>> having them as a parameter (for pre/post) is more than enough, besides
>> easier to implement. If the user really want to customize the image
>> this much, I'd prefer him to go and create his own image by running
>> live-build by hand.
>
> I see at least one argument to prefer linaro-media-create instead of live-build for the job: it will work on other distributions. afaik, live-build isn't available on something else than Debian/Ubuntu, more over we carry a modified version available in our PPA.

Yeah, having linaro-media-create working on any other distro is
already a pain, requesting further customization with live-build is
even worse, +1 for fathi's solution then.

>> >> > 2. Would be useful if we could also copy both scripts at the rootfs
>> >> > 3. Would also be useful if we could stamp that the image was customized
>> by a
>> >> script
>> >>
>> >> for both, I'll leave these outside of l-m-c. It's up to the developer and
>> >> could be done through the hooks.
>> >
>> > I think it can be settled by sorting out if this always will be needed or if
>> there may be cases where the hook author would want no trace of the hooks on
>> the target system. If we feel that we need this for helping people with messed
>> up images we need to do it in l-m-c. If it's up to the developer, I'm happy to
>> leave this bit out.
>
> As a hook author, I don't want trace of the hooks as I want to keep it small :)

Fair enough.

>> Do we have the logs from the l-m-c available at the image already?
>> Guess that this would be enough already.
>
> Do you mean a build log shipped inside the image? We don't have that.
> We can add traces on l-m-c build log (though, it isn't shipped in the generated rootfs).

Yeah, I believe having the build logs is useful, and could be
available at /var/something. But guess this can be tracked by another
bug/merge request.

On Wed, Jan 25, 2012 at 6:31 PM, Ricardo Salveti <email address hidden> wrote:
> On Wed, Jan 25, 2012 at 6:35 AM, Mattias Backman
> <email address hidden> wrote:
>>> Tested with 2 simple scripts and it worked well.
>>>
>>> A few comments:
>>> 1. At the preinstall script there's no way to access the hwpack content,
>>> because it wasn't yet extracted. This may be useful for people that want to
>>> read from hwpack packages or even customize in some way.
>>
>> Would you like the pre-hooks to be run in linaro-hwpack-install instead? That way the script can be run for every hwpack after unpacking it, meaning the pre-hook is run once per hwpack. If you mean we should unpack all the hwpacks and then run the pre-hook once it will require some more work but it is possible of course.
>
> Can you flash the image using more than one hwpack? I thought it'd use
> just one hwpack :-)

You can give as many hwpacks to l-m-c as you like, but most hwpacks
won't make any sense to combine of course. It's intended for having
base and addon hwpacks I think, but I'm not sure it's the most used
feature of l-m-c.

>
> Guess to simplify things having the pre-hook the way you implemented
> should be fine for now.
>
> --
> https://code.launchpad.net/~mabac/linaro-image-tools/scripts-hooks/+merge/89889
> You are the owner of lp:~mabac/linaro-image-tools/scripts-hooks.

On Thu, Jan 26, 2012 at 3:40 AM, Ricardo Salveti <email address hidden> wrote:
> On Wed, Jan 25, 2012 at 4:08 PM, Fathi Boudra <email address hidden> wrote:
>>> On Wed, Jan 25, 2012 at 6:42 AM, Mattias Backman
>>> <email address hidden> wrote:
>>> >> Hi,
>>> >>
>>> >> Do we need the extra command line options? I'm thinking about a hook dir
>>> where
>>> >
>>> > It's all down to how you'd like this to behave, we can do that instead. I
>>> think the discussions on irc kept mentioning command line options which is why
>>> I did that. Any other opinions about cli options vs a hook dir?
>>>
>>> While I like the pbuilder/livebuild way of hooking the script, I think
>>> having them as a parameter (for pre/post) is more than enough, besides
>>> easier to implement. If the user really want to customize the image
>>> this much, I'd prefer him to go and create his own image by running
>>> live-build by hand.
>>
>> I see at least one argument to prefer linaro-media-create instead of live-build for the job: it will work on other distributions. afaik, live-build isn't available on something else than Debian/Ubuntu, more over we carry a modified version available in our PPA.
>
> Yeah, having linaro-media-create working on any other distro is
> already a pain, requesting further customization with live-build is
> even worse, +1 for fathi's solution then.

So we change this to the hooks drop-in folder then.

>
>>> >> > 2. Would be useful if we could also copy both scripts at the rootfs
>>> >> > 3. Would also be useful if we could stamp that the image was customized
>>> by a
>>> >> script
>>> >>
>>> >> for both, I'll leave these outside of l-m-c. It's up to the developer and
>>> >> could be done through the hooks.
>>> >
>>> > I think it can be settled by sorting out if this always will be needed or if
>>> there may be cases where the hook author would want no trace of the hooks on
>>> the target system. If we feel that we need this for helping people with messed
>>> up images we need to do it in l-m-c. If it's up to the developer, I'm happy to
>>> leave this bit out.
>>
>> As a hook author, I don't want trace of the hooks as I want to keep it small :)
>
> Fair enough.
>
>>> Do we have the logs from the l-m-c available at the image already?
>>> Guess that this would be enough already.
>>
>> Do you mean a build log shipped inside the image? We don't have that.
>> We can add traces on l-m-c build log (though, it isn't shipped in the generated rootfs).
>
> Yeah, I believe having the build logs is useful, and could be
> available at /var/something. But guess this can be tracked by another
> bug/merge request.

We brough this up as part of the image metadata discussion. It is a
separate feature but we can probably sneak it in while doing some
other work.

>
> --
> https://code.launchpad.net/~mabac/linaro-image-tools/scripts-hooks/+merge/89889
> You are the owner of lp:~mabac/linaro-image-tools/scripts-hooks.

Follow-up MP using directory paths as arguments to l-m-c: https://code.launchpad.net/~danilo/linaro-image-tools/bug-751531-script-hooks/+merge/98679