On Fri, Apr 01, 2011 at 08:17:29PM +0800, [email protected] wrote: > Hi, > > > -----Original Message----- > > From: ext Anas Nashif [mailto:[email protected]] > > Sent: Friday, April 01, 2011 12:32 PM > > To: Zabaluev Mikhail (Nokia-MS/Helsinki) > > Cc: Boudra Fathi (Nokia-MS/Helsinki); [email protected]; meego- > > [email protected] > > Subject: Re: [meego-packaging] Dropping yaml > > > > > 1. The spectacle format and tools present a learning curve for me, > > while the RPM spec format does not. On a more subjective note, I see in > > Spectacle an unnecessary layer obscuring the actual package > > specification. > > > > How does it obscure the package specification? Does it generate > > something not according to the "standard"? What does it do wrong? > > It forces me to learn another syntax and vocabulary to do what I already know > how to do in detail. Inevitably, there will be new quirks in the new format > and tools that I will have to grapple with. > > > If you package for meego, you need to spend some time "learning" and > > there is really not much to it. > > I did not understand what useful gains this extra learning and tool usage > would give me, considering that usage of spec as the primary package > description syntax has not been prohibited accordingly to the published > guidelines (if one doesn't remember to search mailing list archives or has > learned about it all in the back room where the actual decisions were made). > > 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. > > > > 2. I want to be able to easily import changes in packaging from other > > distributions, or even an OBS upstream such as this one: > > https://build.opensuse.org/package/show?package=telepathy- > > qt4&project=KDE%3AUnstable%3APlayground > > > > One of the reasons we introduced spectacle was exactly to avoid this, > > there is not much in this package to have us copy stuff from other > > distros, it is really a simple case for packaging and thats why it > > works well with spectacle. > > Looks like the %exclude directive is already too much of a stretch: I have to > add it in an ugly customization placeholder section in the spec. As I said, > valuable packaging information is then spread between two sources, which is a > basic software engineering fail. 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. > > I was able to make a fix yesterday in five minutes, while keeping all > relevant information about packaging in one file. Can you help me become more > productive than that and produce maintainable packaging with Spectacle? > > I understand you may need it as means to ensure that common packaging > templates are followed: e.g. a newbie does not fumble his dependencies and > -devel packages while rolling up his first dynamic library. It will be > probably also helpful to make sweeping changes in template-derived packages > without taking time of every maintainer to fix all his/her packages, though > as things are, you'll have to regenerate every spec. But for that to work, > the tools need to become much better. Right, spectacle need more efforts to get better. "spectacle" is part of MeeGo, so it is also an open sourced project, and community contribution is badly welcome. So, if you have ideas about the enhancement, please give us feedbacks, or even change the code. thanks - jf.ding _______________________________________________ MeeGo-packaging mailing list [email protected] http://lists.meego.com/listinfo/meego-packaging
