Talk:Sugar Network/Recipe Specification

Change Logs

Not sure that dates are so important as all the changes are tracked in git anyway. Version number would be important, however. But how does this differ from the info nominally kept in NEWS? Would we still need the NEWS file? --Walter 22:46, 7 February 2011 (EST)

For dates, yeah. In any case, people might use additional keys if they prefer. Might be NEWS as well, though some people (like me) will prefer "self contained" spec files (ie w/o NEWS). So, I guess having assumption that change log can be either in NEWS or in spec file, should be fine. Another reason to have changelog in spec (or in ini file format, ie not like arbitrary NEWS), is that it will be possible to use regular notation for translated strings, eg:

[v1]
changelog = en-text
changelog[ru] = ru-text

alsroot 22:57, 7 February 2011 (EST)

I am fine with using a spec file instead of NEWS, but I am loathe to add yet another place where I track my changes (git commit messages, ASLO release notes, activity page in the wiki, NEWS, and now the spec file). Maybe we either phase out the NEWS file and/or automatically add its updates to the spec file when running "setup.py fix_manifest"? --Walter 08:08, 8 February 2011 (EST)

No questions that having the same data only in one place is a good point. Recipe spec is inspired by the same idea, i.e.: the same spec is activity.info to run activity; the same spec has instruction how to build your activity locally; the same spec has all info to build native packages directly (avoiding intermediate "repackaging") from activity. alsroot

I was not thinking about having NEWS if recipe already contains changelog, though, as silbe said, might useful to reuse debian/changelog files, but in this case would be useful to generate this file (thus do not mess with recipe) from --message command line argument of setup.py or sweets. alsroot 08:39, 8 February 2011 (EST)

Auxiliary Section

A while back, I tried to drum up interest in adding optional fields to activity.info that would enable the developer to communicate to the packager so that the packager would not have to hunt for information needed in creating an .rpm or .deb. Didn't get much traction at the time, but it seems we have an opportunity to exploit your proposal to this end. SDZ had helped me come up with a short list of things that would be trivial for developers to itemize... will try to recreate it. --Walter 08:13, 8 February 2011 (EST)

The core difference here is that new activity.info might be used as direct spec files for packaging on Bazaar, i.e., there is no need to convert some activity.info fields to .spec/.deb, just upload your activity to the server and interested in native packages people will just reuse your uploads. Though it is not intended for official GNU/Linux repos, but the fact that activiti.info has all sufficient fields for having 3rd party rpm/deb, should help official packagers. alsroot 08:33, 8 February 2011 (EST)

+1 --Walter 08:36, 8 February 2011 (EST)

Where does this file live?

I gather from the examples that it lives in the top-level directory? Are we eliminating activity.info? --Walter 20:38, 13 February 2011 (EST)

I'm personally for continue using it, don't see any need in changing the rule. The top level sweets.recipe is for non-activity projects (libraries and applications like sugar). alsroot 21:13, 13 February 2011 (EST)