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. > > 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. 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. Best regards, Mikhail _______________________________________________ MeeGo-packaging mailing list [email protected] http://lists.meego.com/listinfo/meego-packaging
