On 1 Apr 2011, at 15:25, Gabriel M. Beddingfield wrote: > > > On Fri, 1 Apr 2011, Jian-feng Ding wrote: > >> 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. > > Is there some place that actually details out /why/ spectacle is a good idea > and /how/ it is saving people time? The MeeGo wiki just makes these claims as > if its obvious... but after working with spactacle, I don't think it's so > obvious. > > Good features I've seen: > > - Builders (if one exists) > > - Some of the pre/post stuff avoids newbie mistakes > (like not calling ldconfig after installing libs) > > - Nice patch management (add patch in one place, > instead of two places in the spec file.) > > Drawbacks: > > - It does not fully encapsulate the .spec file. > You need both a .yaml and a .spec. I would have > expected this to be a transformation... not some > strange patch-in-place.
for most cases it does, the file list can also be encapsulated in the yaml file. > > - If a builder /doesn't/ exist, you have to rely > on the patch-in-place and your packaging is now > spread across 2 files. > Yes, that is why we need to change the spec inside the placeholders > - Reference documentation is next-to-null (last I > checked). To understand the YAML keywords you have > to already understand what their spec-file analogs > mean and do. > > - spactacle clobbers the changelog (!!). And don't > say, "But oh in OBS we do..." because not everyone > has/uses an OBS workflow, and it's like another secret > handshake. I.e. before `rpmbuild` you have to know > to: > > $ specify foo.yaml > $ mv foo.spec tmp.spec > $ cat tmp.spec foo.changes > foo.spec > $ cp foo.spec ~/rpmbuild/SPECS > > This, um, doesn't save me time... and isn't > newbie-friendly > No it does not, because in MeeGo the changelog is not maintained in the spec file. > - The .yaml files seem like... well, spec files with > a different syntax. And since the whole point is > to generate a spec file, why not just do the spec file? Because of the good features you have listed and many others. > > - To a newbie, having to learn BOTH spectacle and .yaml > is not easy. Because when you mess up the .yaml file, > you have to know enough .spec to grok what you did > wrong (because .spec is where the rubber meets the > road). > Yes, once a package is not straightforward anymore, things can get hairy, but for most cases it is really isnt and people should not spend too much time on figuring out packaging, spectacle helps there. > There's my feedback. I'm still not sold on the concept... so don't expect > any code until I am. :-) thanks, very helpful. Now, I want to say that again. Nobody is forcing anybody to use spectacle, and as the wiki says, it is not mandatory. You might not like it, thats ok, but it is being used successfully in many packages and by many package maintainers, even with all of the above drawbacks, when you get used to it, it is still much easier than dealing with spec files. Maybe we just need to clarify the rules and move forward. I personally hate it when a package fix or change gets blocked because of something like that, this is counter-productive. Take the guidelines on the wiki and come up with a better proposal if you wish, but lets not waste too much time on something like that. At the end of the day, what matters is the spec file, and if it is well maintained and kept up with the rest of the distribution, then I do not care how it was created, using spectacle or manually or whatever. So there are 2 things need to be improved: - Work on the drawbacks above and probably other bugs/feature requests - Finally figure out the rules, agree on them and follow them Anas > > -gabriel > > _______________________________________________ > 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
