Re: maemo-optify, autobuilder & /opt

ext Ed Bartosh <bartosh@gmail.com> writes:

> 2009/11/5 Marius Vollmer <marius.vollmer@nokia.com>:
>
>> Then I propose to put maemo-optify into the sdk repo, add a dependency
>> to it from build-essential and make a new SDK release.
>>
>> Whenever we need to update maemo-optify, we need to make a new
>> rootstrap.
>>
> It would take a lot of time, I think.
>
> I have another idea. If it doesn't work proper way let's make a hack
> in autobuilder. Autobuilder will run maemo-optify-deb after the
> build.

Hmm, aren't we now trying to solve the problem of how to get
maemo-optify into the build environment, not how to run it once it's
there?

I.e., we have modified the debian-etch devkit to call maemo-optify-deb
at the right time. That modification to the devkit is 'stable'. It is
quite unlikely that we need to change the devkit again.

> It will be run on garage, so anybody, who has root@garage can
> update package there.
> How does it sound?

What would root@garage need to do, exactly? Create new rootstraps? Run
apt-get install maemo-optify once in a while? (Run pbuilder --update? :)

If root@garage can do it, could the auto-builder do it as well?

2009/11/5 Marius Vollmer <marius.vollmer@nokia.com>:
> ext Ed Bartosh <bartosh@gmail.com> writes:
>
>> 2009/11/5 Marius Vollmer <marius.vollmer@nokia.com>:
>>
>>> Then I propose to put maemo-optify into the sdk repo, add a dependency
>>> to it from build-essential and make a new SDK release.
>>>
>>> Whenever we need to update maemo-optify, we need to make a new
>>> rootstrap.
>>>
>> It would take a lot of time, I think.
>>
>> I have another idea. If it doesn't work proper way let's make a hack
>> in autobuilder.  Autobuilder will run maemo-optify-deb after the
>> build.
>
> Hmm, aren't we now trying to solve the problem of how to get
> maemo-optify into the build environment, not how to run it once it's
> there?
>
We were trying to solve the problem right way, but it looks like we
failed unless sbdmock author will accept the change or I'll decide to
fork sbdmock.

What I propose is to run maemo-optify-deb not on the build host inside
scratchbox, but on garage, after all packages have been already built.
I don't like this hack, but it looks like we run out of ideas.

> I.e., we have modified the debian-etch devkit to call maemo-optify-deb
> at the right time.  That modification to the devkit is 'stable'.  It is
> quite unlikely that we need to change the devkit again.
>
>> It will be run on garage, so anybody, who has root@garage can
>> update package there.
>> How does it sound?
>
> What would root@garage need to do, exactly?  Create new rootstraps?  Run
> apt-get install maemo-optify once in a while?  (Run pbuilder --update? :)
>
Run apt-get install maemo-optify on the garage when it's updated.

> If root@garage can do it, could the auto-builder do it as well?
autobuilder is run from non-root account and garage is pretty
important place. It's better to do it manually when needed.

--
BR,
Ed

2009/11/5 Ed Bartosh <bartosh@gmail.com>:
> 2009/11/5 Marius Vollmer <marius.vollmer@nokia.com>:
>> ext Ed Bartosh <bartosh@gmail.com> writes:
>>
>>> 2009/11/5 Marius Vollmer <marius.vollmer@nokia.com>:
>>>
>>>> Then I propose to put maemo-optify into the sdk repo, add a dependency
>>>> to it from build-essential and make a new SDK release.
>>>>
>>>> Whenever we need to update maemo-optify, we need to make a new
>>>> rootstrap.
>>>>
>>> It would take a lot of time, I think.
>>>

I've discussed this with sbdmock author and we decided to make small
change to sbdmock:
New configurable action will be introduced. This action will be
executed by sbdmock between unpacking rootstrap and installing
build-deps.

For Fremantle we can simply put 'apt-get install maemo-optify' in there.

I'll try to make this change on weekends and deploy new sbdmock and
devkit in production.

It would be nice If somebody could explain me what should I expect
from maemo-optify in the following cases:
- source package doesn't contain anything /opt specific, binary
package doesn't contain /opt
- source package doesn't contain debian/optify, binary package doesn't
contain /opt
- source package doesn't contain debian/optify, one binary package
doesn't contain /opt, another binary package does
- source package contains debian/optify, binary package contains /opt
- source package contains debian/optify, one binary package contains
/opt, another binary package doesn't
....

Thanks,

--
BR,
Ed