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 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.