Le 28/11/2014 09:10, Markus Lehtonen a écrit :
There would be a distinction between "fully automatically maintained" spec
files and "semi-automatically" maintained spec files.
For the fully automatic case, spec metadata would be auto-generated and
pushed to git on every ref update, effectively overwriting any manual
changes. In the semi-automatic case there would be no automatic push to
the branch but a patch would be submitted to gerrit, instead. This would
allow some maintainer control (with a risk of some meta data divergence,
unfortunately) and not force to use bb metadata outright.
The distinction between the fully/semi automatic would be defined in the
bb metadata of the package.
Thus, changes to .spec file are not explicitly denied (I don't even know
how to implement something like that) but changes might get automatically
overwritten (for the fully automatic packages).
Ed,
having such exception will not be manageable and shall not be enabled.
If for any reason the business logic of the bb->spec translator is known
to fail on a given list of packages due to their very weird
construction, the tool will need to embedded a special logic for those
packages.
This is not very different of the model used in the tool spec2yocto
which has been used to prototype Tizen build on Yocto earlier this year.
Having a dual maintenance model is not an acceptable solution.
Regards
Dominig ar Foll
Senior Software Architect
Open Source Technology Centre
Intel SSG
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
