[meego-packaging] Dropping yaml

[mikhail.zabaluev at nokia.com]

Hi,

> -----Original Message-----
> From: ext Jian-feng Ding [mailto:jian-feng.ding at intel.com]
> Sent: Saturday, April 02, 2011 6:05 AM
> To: Zabaluev Mikhail (Nokia-MS/Helsinki)
> Cc: nashif at linux.intel.com; meego-packaging at meego.com
> Subject: Re: [meego-packaging] Dropping yaml
> 
> > The REAL REAL problem of the spec/yaml mess is, the normal action of
> specify is not to generate a spec file completely from the yaml source.
> It expects to see some older cruft in the spec, and merge it with the
> changes in yaml. So, both files are largely redundant sources for one
> result. This cannot work right and is against principles of good
> software engineering: you should never be encouraged to generate one
> thing from another and then hack the generated thing.
> 
> Actually, your understanding of spectacle is not right.
> We can easily put the placeholder enclosed stuff into another separated
> file, e.g. "custom", and regard the YAML+custom
> as the only source for the generated spec, which need not to be touched
> again.

Care for a HOWTO?
It's hard to get correct understanding of Spectacle features which are not documented.
And still, keeping all information in one spec file wins in maintainability over "yaml+custom" in my opinion.
And hey, I know how to use macros to not edit much of the variable information repeatedly.
If most of MeeGo maintainers don't have this kind of knowledge, I'd say it's a human resources problem, which you are trying to solve with technical means.

> Now we just put the "custom" parts inside the spec, and even more, you
> can consider the generated spec to be two parts:
> the auto-generated part and the "custom" part.

No, I usually consider a generated file to be a build product which must not be changed manually.

> BTW, I think the MeeGo packaging guidelines is quite clear and can be
> easy to follow:
>  1. spectacle is not mandatory
>  2. But for the spectacle ready packages, please follow the previous
> maintainers except you met technical difficulty
>     that cannot be resolved by spectacle, not just because of dislike
> or sth. else.

Please make sure these guidelines are agreed with MeeGo steering board AND DOCUMENTED.

NB: my particular difficulties are not unresolvable by Spectacle, it's just that I consider the solution less maintainable, especially for somebody who already knows RPM than working with spec directly.

Cheers,
  Mikhail