− | It would facilitate the packaging of Sugar activities into RPMs and DEBs if there were additional information available in the activity.info file | + | It would facilitate the packaging of Sugar activities into RPMs and DEBs if there were additional information available in the activity.info file. |
− | ''Note:'' While I am proposing this new feature, I am not in any way qualified to implement it as I have never built an RPM or DEB | + | ''Note:'' While I am proposing this new feature, I am not in any way qualified to implement it as I have never built an RPM or DEB. |
− | In walking the process of creating an RPM of one of my activities with SDZ, who is doing lots of packaging for Fedora and SoaS, we observed that many fields in the desktop spec file could readily be pulled from the activity.info file. A few additional fields would be necessary, such as a short summary, a URL to the activity home page, and the URL of the activity tarball on DSLO. 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.) | + | In walking the process of creating an RPM of one of my activities with [[User:Sdz|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 a short summary, an URL to the activity home page, and the required dependencies for the activity 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.) |