Re: [Sugar-devel] [Feature] activity.info enhancements
On Fri, Dec 11, 2009 at 17:18, Sayamindu Dasgupta sayami...@gmail.com wrote: On Fri, Dec 11, 2009 at 11:13 PM, Walter Bender walter.ben...@gmail.com wrote: Summary: It would facilitate the packaging of Sugar activities into RPMs and DEBs if there were additional information available in the activity.info file. Details: In walking the process of creating an RPM of one of my activities with Sebastian Dziallas, who is doing lots of packaging for Fedora and SoaS, we observed that many fields in packages' .spec files could readily be pulled from the activity.info file. A few additional fields would be necessary, such as the following: * a short summary * an URL to the source package * an URL to the activity home page * the required dependencies to run None of these additional fields are particularly onerous for an activity developer to provide and it would enable the creation of a script (as part of setup.py/bundlebuilder.py) to do most of the work in creating the .spec file. (I assume .deb has similar requirements to .rpm). Things are more complex for activities that include binaries and the like, but for the most part, we should be able to greatly facilitate upstream maintenance of our code while asking little more of Sugar developers. None of these additional fields need be required, but their inclusion would make things easier. (This is not a new idea, but one that seems timely given all the upstream interest in Sugar these days.) It may be interesting to factor in localization (eg: translation of the description, etc) into this discussion. We already translate parts of activity.info so it may be trivial to extend the mechanism. However, it does increase the workload on translators a bit, and we need to agree on which fields to translate (for example, if we have a non-UI-visible field called category or tags, it may not make sense to translate it). I was thinking of displaying these tags in the activity list (or it's already happening, not sure). Also, if we allow searching for those, we would need to do so with the ones in the local language. Regards, Tomeu It may also be worthwhile to keep some kind of compatibility with the desktop-entry spec http://standards.freedesktop.org/desktop-entry-spec/latest/, in case we add support for standalone activities in the future. Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Feature] activity.info enhancements
On Fri, Dec 11, 2009 at 2:26 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Fri, Dec 11, 2009 at 17:18, Sayamindu Dasgupta sayami...@gmail.com wrote: On Fri, Dec 11, 2009 at 11:13 PM, Walter Bender walter.ben...@gmail.com wrote: Summary: It would facilitate the packaging of Sugar activities into RPMs and DEBs if there were additional information available in the activity.info file. Details: In walking the process of creating an RPM of one of my activities with Sebastian Dziallas, who is doing lots of packaging for Fedora and SoaS, we observed that many fields in packages' .spec files could readily be pulled from the activity.info file. A few additional fields would be necessary, such as the following: * a short summary * an URL to the source package * an URL to the activity home page * the required dependencies to run None of these additional fields are particularly onerous for an activity developer to provide and it would enable the creation of a script (as part of setup.py/bundlebuilder.py) to do most of the work in creating the .spec file. (I assume .deb has similar requirements to .rpm). Things are more complex for activities that include binaries and the like, but for the most part, we should be able to greatly facilitate upstream maintenance of our code while asking little more of Sugar developers. None of these additional fields need be required, but their inclusion would make things easier. (This is not a new idea, but one that seems timely given all the upstream interest in Sugar these days.) It may be interesting to factor in localization (eg: translation of the description, etc) into this discussion. We already translate parts of activity.info so it may be trivial to extend the mechanism. However, it does increase the workload on translators a bit, and we need to agree on which fields to translate (for example, if we have a non-UI-visible field called category or tags, it may not make sense to translate it). I was thinking of displaying these tags in the activity list (or it's already happening, not sure). Also, if we allow searching for those, we would need to do so with the ones in the local language. I think displaying them in the list might just add visual noise, but their primary intent is to allow searching, and as you point out, it's critical to have good translations for that to work. Eben Regards, Tomeu It may also be worthwhile to keep some kind of compatibility with the desktop-entry spec http://standards.freedesktop.org/desktop-entry-spec/latest/, in case we add support for standalone activities in the future. Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Feature] activity.info enhancements
On Fri, Dec 11, 2009 at 12:43:56PM -0500, Walter Bender wrote: Summary: It would facilitate the packaging of Sugar activities into RPMs and DEBs if there were additional information available in the activity.info file. Details: In walking the process of creating an RPM of one of my activities with Sebastian Dziallas, who is doing lots of packaging for Fedora and SoaS, we observed that many fields in packages' .spec files could readily be pulled from the activity.info file. A few additional fields would be necessary, such as the following: * a short summary * an URL to the source package * an URL to the activity home page * the required dependencies to run Having such info could be really messy, various distors have various naming schemes, some programs could be splited to several packages etc. If it will be formal info why do not just use regular README/INSTALL/etc files, it it will be formal info, why invent another packaging scheme instead of reusing existed(e.g. 0install as was proposed in [1]). [1] http://wiki.sugarlabs.org/go/Zero_Install_integration None of these additional fields are particularly onerous for an activity developer to provide and it would enable the creation of a script (as part of setup.py/bundlebuilder.py) to do most of the work in creating the .spec file. (I assume .deb has similar requirements to ..rpm). Things are more complex for activities that include binaries and the like, but for the most part, we should be able to greatly facilitate upstream maintenance of our code while asking little more of Sugar developers. None of these additional fields need be required, but their inclusion would make things easier. (This is not a new idea, but one that seems timely given all the upstream interest in Sugar these days.) See: http://wiki.sugarlabs.org/go/Features/Feature_ActivityInfo -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Feature] activity.info enhancements
On Fri, Dec 11, 2009 at 12:43:56PM -0500, Walter Bender wrote: Summary: It would facilitate the packaging of Sugar activities into RPMs and DEBs if there were additional information available in the activity.info file. Details: In walking the process of creating an RPM of one of my activities with Sebastian Dziallas, who is doing lots of packaging for Fedora and SoaS, we observed that many fields in packages' .spec files could readily be pulled from the activity.info file. A few additional fields would be necessary, such as the following: * a short summary * an URL to the source package * an URL to the activity home page * the required dependencies to run I would use such hints only as inspiration for Debian packaging, not rely on it. The reason for this is that I would not expect upstream software authors to know all the nitty gritty details of policies governing Debian packaging - e.g. how we name the dependencies. Even if they did know better than me I still would need to double-check, as ultimately I am responsible for the quality of packaging that I maintain, not upstream. Since the hints most likely won't be machine-processed (I suspect other distributors will do as me - it seems irresponsible to me to automate), I strongly recommend to use the de-facto GNU filenames: INSTALL for notes relevant only at install time (i.e. both for manual install and for distributors) and README for hints targeted end-users. None of these additional fields need be required, but their inclusion would make things easier. (This is not a new idea, but one that seems timely given all the upstream interest in Sugar these days.) I guess you meant _downstream_ interest above. Distributors are downstream to Sugarlabs, only GTK+, Python and similar are upstream, and I suspect that's not the ones gaining interest in Sugar. Kind regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Feature] activity.info enhancements
On Fri, Dec 11, 2009 at 8:20 PM, Jonas Smedegaard d...@jones.dk wrote: On Fri, Dec 11, 2009 at 12:43:56PM -0500, Walter Bender wrote: Summary: It would facilitate the packaging of Sugar activities into RPMs and DEBs if there were additional information available in the activity.info file. Details: In walking the process of creating an RPM of one of my activities with Sebastian Dziallas, who is doing lots of packaging for Fedora and SoaS, we observed that many fields in packages' .spec files could readily be pulled from the activity.info file. A few additional fields would be necessary, such as the following: * a short summary * an URL to the source package * an URL to the activity home page * the required dependencies to run I would use such hints only as inspiration for Debian packaging, not rely on it. The reason for this is that I would not expect upstream software authors to know all the nitty gritty details of policies governing Debian packaging - e.g. how we name the dependencies. Even if they did know better than me I still would need to double-check, as ultimately I am responsible for the quality of packaging that I maintain, not upstream. Since the hints most likely won't be machine-processed (I suspect other distributors will do as me - it seems irresponsible to me to automate), I strongly recommend to use the de-facto GNU filenames: INSTALL for notes relevant only at install time (i.e. both for manual install and for distributors) and README for hints targeted end-users. None of these additional fields need be required, but their inclusion would make things easier. (This is not a new idea, but one that seems timely given all the upstream interest in Sugar these days.) I guess you meant _downstream_ interest above. Distributors are downstream to Sugarlabs, only GTK+, Python and similar are upstream, and I suspect that's not the ones gaining interest in Sugar. Yes. Downstream. I based my proposal on a discussion with only a small sample of packagers. I take it from both Jonas and Aleksey that there may be better ways of assisting packagers. The goal is that activity developers do have a lot of knowledge about their creations and it would make sense to have them express it in some way that would save work for others. But what form this expression takes I leave to those more knowledgeable. Jonas, it may make sense not to depend on things like dependency names, etc. but I can imagine things like a summary, description, URL of the homepage, etc. could be reasonable to accept from developers. please advise. -walter Kind regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCgAGBQJLIu/sAAoJECx8MUbBoAEhtZwP/iZ3Ea4vRK8lu5e1J1IY8pjZ JgOrp0WEy57bKFqGaCbpt1Ugpx1U149wWlv7sgr2yl0gex5ztUaLpF/Z2R6MUJf1 8W9Yax5iuROI0sfoAd896TZXxIjps7E/0Ai63NzyLfnlqrhcnmJ305Qp07JcdvxP Gf1QBfURDgzjd1u5CyFePkRd9u6Nwg0xu7cQ1vey0F2XUtGHrYl0hVo7oaldn+n7 l6+yf+j+SVnG3hBiWIERRoTtPSu4hw2vKk4bd/rbtFGnHFwdk8ZW3NCZ1+ftwZ5F w5QI7NxMjWCGnBP0jC/YNiab0X3Ah84Dk08uZ4Dt3Jdlt9y5eFILGGSvMfY6Vvpb 5cczmuMqWfxAdx66vESq7vl6bAC+KfT6wT+aUBo7dBQaNByVE4D4I1c1kxGsbqsP AyRCDJTzkjBvY6aIu6dflWKfIRELizS7boToXRGSqTZzc36cx/GiOWsd7x9CYTez R+vQP5IztxmNFCrbvr0tihqTZ4Dv0fAoY44TFtFr+SZ2akWE7mfZ0ZHZJ3232bTE xHSfLxa7l0sYciJk2Sbrnp9O3KeSkCSonwxmjipsN01gmYbg8WIrKGGebZ8M7VUd CU2k4AIfSU2mqYrj830HEX3BbHhyWUvjF1N75tpgPG8D/VQfDsWHcOSoaHzzaGZy LzUbbZBeAU41ul+fHPmK =NeY0 -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Feature] activity.info enhancements
On Fri, Dec 11, 2009 at 09:39:15PM -0500, Walter Bender wrote: On Fri, Dec 11, 2009 at 8:20 PM, Jonas Smedegaard d...@jones.dk wrote: On Fri, Dec 11, 2009 at 12:43:56PM -0500, Walter Bender wrote: Summary: It would facilitate the packaging of Sugar activities into RPMs and DEBs if there were additional information available in the activity.info file. I would use such hints only as inspiration for Debian packaging, not rely on it. None of these additional fields need be required, but their inclusion would make things easier. (This is not a new idea, but one that seems timely given all the upstream interest in Sugar these days.) I guess you meant _downstream_ interest above. Distributors are downstream to Sugarlabs, only GTK+, Python and similar are upstream, and I suspect that's not the ones gaining interest in Sugar. Yes. Downstream. :-) I based my proposal on a discussion with only a small sample of packagers. I take it from both Jonas and Aleksey that there may be better ways of assisting packagers. The goal is that activity developers do have a lot of knowledge about their creations and it would make sense to have them express it in some way that would save work for others. But what form this expression takes I leave to those more knowledgeable. I certainly agree that sharing such info makes good sense - it only worried me if using a machine-readable format as that could create an expectation among activity developers of it being used automatically by distributors which I wouldn't do myself and recommend against others doing either. Jonas, it may make sense not to depend on things like dependency names, etc. but I can imagine things like a summary, description, URL of the homepage, etc. could be reasonable to accept from developers. It makes good sense for upstream to clearly express such metadata, but I still see it as distribution choice if using it verbatim or not. As an example, the distributor may have a different interpretation of Homepage than upstream (as has been discussed before on this list). If you really want to use a machine-readable format then I recommend using DOAP instead of reinventing the wheel. But even if you do, I still recommend to use an INSTALL file as well. Hope that makes sense. If not please keep arguing! :-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
