[meego-packaging] Dropping yaml

[Selbak, Rolla N]

On 4/4/11 3:22 AM, "mikhail.zabaluev at nokia.com"
<mikhail.zabaluev at nokia.com> wrote:

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


I think this makes a lot of sense.

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

Documented here already:

http://wiki.meego.com/Packaging/Guidelines#Writing_a_package_from_scratch

I made one minor change right now:

-OLD: You need to have a valid reason why not to use the yaml format (not
having time to learn spectacle is not a good reason)


+NEW: If a package is already using the yaml format, you need to have a
valid reason why not to use the yaml format

rs


>
>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
>_______________________________________________
>MeeGo-packaging mailing list
>MeeGo-packaging at meego.com
>http://lists.meego.com/listinfo/meego-packaging