On Fri, Apr 01, 2011 at 09:10:21PM +0800, [email protected] wrote:
> Hi Jian-feng,
>
> > -----Original Message-----
> > From: ext Jian-feng Ding [mailto:[email protected]]
> > Sent: Friday, April 01, 2011 3:49 PM
> > To: Zabaluev Mikhail (Nokia-MS/Helsinki)
> > Cc: [email protected]; [email protected]
> > Subject: Re: [meego-packaging] Dropping yaml
> >
> > > It's not like the spec format is that complicated so it would be
> > easier to learn a whole new set of keywords like AsWholeName (damn,
> > it's NSFW to even talk about spectacle packages in the office :)). And
> > wrack my mind guessing why BuildRequires needed to be obfuscated with
> > PkgBR, and other such riddles.
> >
> > Apparently, I believe you have got the meanings of "AsWholeName" and
> > "PkgBR" now. Yes, it's very easy to following,
> > there's nothing too complicate or magic in spectacle. Just calm down
> > and learn something new with a little effort.
>
> (Checking the date of your mail)
> Yeah, that's right. *chuckle*
>
> > > And the buggy
> > > version of specify in the current tools repository forces me to edit
> > > both of these files to remove some binary packages.
> > No, in your case, specify is not BUGGY, it just report the REAL problem
> > of the spec/yaml files in a obscure way.
>
> 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.
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.
And the "custom" part will not be changed frequently in the packages
maintenance, in most cases what we need to do is to
modify the YAML, which is easier to control than original spec, at least I
feel. So current solution is smart enough, at
least not SO BAD.
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.
Thanks
- jf.ding
>
> Best regards,
> Mikhail
_______________________________________________
MeeGo-packaging mailing list
[email protected]
http://lists.meego.com/listinfo/meego-packaging
