On 4/4/11 3:22 AM, "[email protected]" <[email protected]> wrote:
>Hi, > >> -----Original Message----- >> From: ext Jian-feng Ding [mailto:[email protected]] >> Sent: Saturday, April 02, 2011 6:05 AM >> To: Zabaluev Mikhail (Nokia-MS/Helsinki) >> Cc: [email protected]; [email protected] >> 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 >[email protected] >http://lists.meego.com/listinfo/meego-packaging _______________________________________________ MeeGo-packaging mailing list [email protected] http://lists.meego.com/listinfo/meego-packaging
