I want to propose that we have a common CVS area for package source code.

Unless there is a more suitable place (perhaps associated with openwrt.ksilebo.net), then the existing (but unused) SourceForge CVS repository would be a good place for this.  We could fairly openly give write access to OpenWRT developers (as opposed to users who would just have read-only access if they wanted to get package source code) by making them members of the OpenWRT SourceForge project.  We could use the bug tracking mechanism there to track package bugs.  We would still use the forums here for discussion about packages and package development.

The benefits of a common CVS area for package source code are:

1/ We comply with our GPL responsibilities for GPL'd packages without any extra effort.  No-one can make the sort of accusations which have previously been levelled at Sveafost, Wifi-Box and even OpenWRT (all of which have now released source code, but the repercussions of the accusations still cause bitterness in the WRT54G third-party firmware community).

2/ We always know where the latest bleeding-edge version of every package lives, and we can help fix bugs in each other's packages.

3/ We can use CVS tags to define the latest "stable" set of packages, and perhaps even use that to automatically generate the public packages area on openwrt.ksilebo.net.

4/ We get to see each others code and hopefully converge on a common packaging environment (as opposed to the existing common openwrt buildroot environment which is currently used for building the initial firmware, not packages).  It would be good if the buildroot environment and the packaging environment were one and the same tree.

5/ The main OpenWRT developers have access to a test suite of package source code which they can use (if desired) to check that changes to the basic OpenWRT code and modules don't have an adverse effect on packages.

What do you other developers think ?

-- Rod

Totally in agreement, but before this happens a few things must be agreed upon.

* common structure for ipkg source should be agreed upon
* One CVS module per ipkg?
* common template to copy for each base ipkg definition & build script
* mjn3 talked about the possibility of creating a standard within the buildroot for package building.

Agreed.  Is anyone working on these common structures and standards for package building (as opposed to for basic firmware building) ?

I would expect one CVS module per ipkg.  Then you could control write access with CVS admin files if necessary - but I would expect that we could trust the developers not to mess with each other's files.  People could also then just check out the packages they wanted, and it also makes sure that package names don't collide.

-- Rod

Part of the standardized structure for packages in CVS is not only package name, but also version.  How should version be tracked?  I am assuming ipkg handles upgrading to new versions of already installed packages right?

One idea is for the ipkg versions to be an extension of the CVS version tags.  That way a simple tool or macro used during ipkg building always results in a unique package version.  Fedora uses this kind of automated versioning for kernel packages for example.  CVS branches are expressed as another "." and a new incrementing number appended to the end.

Example
cipe-1.5.4-18
This could be the 18th revision of cipe within CVS.
cipe-1.5.4-18.PKCIPE.1
This could  be an experimental OpenWRT branch, say with PKCIPE enabled.

The actual naming scheme would be similar to this but I am not sure how at this moment since I still know nothing about ipkg, but you should get the basic idea.

Unless it's a custom package I see no reason to to store the entire sources in cvs; if it's a standard GPL'd program just write a script to compile and possibly commit that to cvs. A cvs module per script would be overkill.

Seeing as we already have the  buildroot structure in place we can probably just extend that to build ipkgs.

Yeah - I see your point and agree.  I need to get my head into "buildroot" mode when I think about these things ...

-- Rod

okay, but the download & build makefile template for ipkg's should check at least the md5sum of the tarball that it downloads.  Then make sure the CVS has a set of "known good" tarballs.  Let me know when you get to this point and I have a bunch of in production scripts used by other projects to use as a sample.

Are these scripts which link against uClibc ?

-- Rod

Do you have the scripts (or source code patches) available for the packages that are currently available ?

I'd like to contribute a HeartBeat (bpalogin) package, but I don't want to be accused of violating the GPL, so I want to upload a script or patch to the same place as the package (or whever all the other source code for the existing GPL packages is stored - BTW where is that?).

-- Rod

An interesting topic I thought I'd revisit.  Did anything come of this discussion?  Looking through the package repositories reveals that many OpenWRT packages don't have source-code patches available. 

The legal ramifications of this don't worry me as much as just the plain inconvenience of having to start from scratch to repackage an app if the original packager abandons it.  What's the solution to this?

PS. If there was no modification was necessary to cross-compile the ipk, either to the source-code or the makefile, then it would be nice if the package info said that somewhere.

Most of the developpers do give access to the source they used and also the makefile they produced.

I think that we should agree on one thing : do we keep the .mk file or use ipkg rulesets to make ipks ?