brokenman wrote:There were definitely certain files it didn't like and would drop out ... from memory in /dev
That makes sense as svn does not deal with character/block devices. Better off completely removing all /dev entries and recreating them after checkout/export with makedev.
brokenman wrote:The entire Porteus OS is tied up in the base modules. When i say source files i mean that these have been unpacked, and the total decompressed size is over 1Gb. Offering anything less than the entire file set is a broken OS.
I figured as much and agree with you on offering the entirety of the OS. Where we differ is in how best to accomplish this. I am advocating that sources/binary files be kept out of the svn repo. I am expanding on this below.
brokenman wrote:I guess this is an option, but we don't use the standard packages offered by the repo for alot of the base modules. They are stripped down and in some cases only a few files used. This would over complicate the process.
The end result of a stripped package is due to developers like yourself pruning files through manual means and/or hopefully scripts at this point. This effort should be recognized for the time consuming work and potential to impact the project. Right now that work is summarized by one line svn commits that impart
little information. Why settle for that level of verbosity, when you could
easily see the work done. Take for example, the omission/deletion of some trivial library (libfoo.so), in your current workflow
on your machine you can determine the error fairly quickly by either running svn log or svn diff. In either case, the svn output will let you find the problem quickly. But for the other developers, they will have to do two checkouts/exports of a few compressed xzm files (~300MBx2) to even find this bug. All due to the fact, that svn cannot actually calculate deltas between binary files.
So what would a ideal repo/workflow look like ? Your standard svn repo configuration of trunk, branches and tags would be valid. The benefit of tags is easy enough to understand, as you can tag a certain revision as being stable, testing, nightly, 1.0, etc.. The branches make it easy to work on the next version of porteus perhaps even changing sources/packages without mucking up the trunk branch, which could be reserved for bugfixes. The trunk branch could consist of multiple script files for each individual package or one script file for each .xzm that processes all the packages necessary for that module. The processing could involve everything from removing/stripping files, compressing manpages to creating symbolic links. This might seem like a daunting task, but all the information to reduce files in a package can be obtained by comparing the package logs to the actual filesystem.
I understand the concern for over complicating the process, but I believe that establishing a good workflow will ease your future work. Here's a couple of payoffs off the top of my head.
1. AFAIK, current Porteus x86_64 is based on a slackware-current of some date unknown to me. What happens when slackware-current goes through a huge change (KDE4.7), How do you get updated/security packages in ? Would it not be easier to let loose the old versioned scripts against the new packages and see what breaks and what doesn't, instead of manually performing the individual package upgrade drudgery. I am assuming that work right now is still manual and not automated.
2. You could potentially attract more developers. SLAX is a good example of how a good project can be overcome by actual life. Porteus will need to attract lots of helping hands to overcome potential stagnancy. Fanthom's time spent understanding the entire build process was likely tedious, sparing other developers this pain will only benefit the project.
I am a bit rushed and hope that I have expressed my ideas somewhat clearly. The summary is basically to house recipe files in the repo and keep packages outside. My comments are not meant to be condemnation of the existing process, but just my own experiences in managing my own projects. Time permitting..I am happy to help with a trial test of some these methodologies.
P.S If you haven't tried
Mercurial or
Trac, you should take a look. Nothing better than hosting your projects on a portable LAMP/Hg/Trac stack running out of
SLAX Porteus (soon) booted from a SLAX PXE server.