Difference between revisions of "Autocurated Packages"
Jon Phillips (talk | contribs) (→Makefile.conf) |
Jon Phillips (talk | contribs) (→Makefile) |
||
Line 13: | Line 13: | ||
The makefile should have basic infrastructure to ubild packages into a /packages folder | The makefile should have basic infrastructure to ubild packages into a /packages folder | ||
+ | |||
+ | '''NOTE:''' To save massive time, re-use and/or build-upon the work done on the Makefile on ccHost: | ||
+ | |||
+ | https://cctools.svn.sourceforge.net/svnroot/cctools/cchost/trunk/Makefile | ||
+ | https://cctools.svn.sourceforge.net/svnroot/cctools/cchost/trunk/Makefile.dist | ||
+ | https://cctools.svn.sourceforge.net/svnroot/cctools/cchost/trunk/Makefile.include | ||
+ | https://cctools.svn.sourceforge.net/svnroot/cctools/cchost/trunk/Makefile.language | ||
+ | |||
+ | Although, I don't think that the Makefile.language will be needed (yet) ;) | ||
=== Makefile.conf === | === Makefile.conf === |
Revision as of 19:22, 1 October 2007
The idea of auto-curated packages is that high-quality content can be pulled from media hosting sites that support a RESTful API for getting CC licensed content. The community from these sites has peer reviewed content so that it makes it easy to automatically pull down a top ten best tracks, or something similar, and then timestamp them, and package them for inclusion onto various devices.
While there are many sites on the web, having the ability to package content on the fly is akin to packaging of an album, producing a checkout item, and is vitally important for platforms like the OLPC and OpenMoko who rely upon package management for their limited storage space.
Contents
Brain Dump
In a folder like 'jamendo' have the following files:
Makefile
The makefile should have basic infrastructure to ubild packages into a /packages folder
NOTE: To save massive time, re-use and/or build-upon the work done on the Makefile on ccHost:
https://cctools.svn.sourceforge.net/svnroot/cctools/cchost/trunk/Makefile https://cctools.svn.sourceforge.net/svnroot/cctools/cchost/trunk/Makefile.dist https://cctools.svn.sourceforge.net/svnroot/cctools/cchost/trunk/Makefile.include https://cctools.svn.sourceforge.net/svnroot/cctools/cchost/trunk/Makefile.language
Although, I don't think that the Makefile.language will be needed (yet) ;)
Makefile.conf
This Makefile.conf should have simple variables in the header of the file so that it is easy to target a different media hosting site and generate a new package
Another idea is to have multiple confs like: openclipart.org.conf, jamendo.com.conf, and then the make dist and/or make all read in all conf's automatically...this would be useful!
Features should include
- variable NUM_OF_FILES=10
- variable LICENSE=BY
- variable URL, like URL=http://jamendo.com/get?toptracks&num=${NUM_OF_FILES}&license=${LICENSE}
Steps to build the package
- use curl to get content from the URL into a folder, called 'content'
- make packages from this content folder like the following, into directory, called 'packages'
- jamendo_`date +%F`.tar.gz
- jamendo_`date +%F`.tar.bz2
- jamendo_`date +%F`.zip
- jamendo_`date +%F`.xo1 (zip for olpc)
- call .spec file to make rpms
- jamendo_`date +%F`.rpm
- create .deb with alien or the like, or directly
- jamendo_`date +%F`.deb
To generate all packages:
make dist
To generate specific {tar.gz,tar.bz2,zip,xo1,rpm,deb,ebuild} package:
make PACKAGE_TYPE
Example:
make xo1
.spec file
The spec file should simply use the generated tarball and Makefile to make an RPM. After this is done, then it will be easy to put these package builds, which will change possibly upon each run of the script, into a build system and for by use of RPM-based distributions.
Other Packaging System
Also, there could easily be wrapper scripts for generating .deb packages necessary for debian-based distributions like Ubuntu. One can use the program 'Alien' to convert from an RPM to a .deb package.
Also, gentoo ebuilds would be another interesting target.