(crossposted to staden-devel, for some expert opinion on staden usage) On Tue, Nov 4, 2008 at 12:20 PM, Andreas Tille <[EMAIL PROTECTED]> wrote:
> On Tue, 4 Nov 2008, Lelanthran Manickum wrote: > > <snipped> > > > I've debianised staden 1.7.0 and placed it here. >> > > Great - but you seem to have forgot to insert a link. > Whoops! Sorry about that. <https://launchpad.net/%7Escubuntu-dev/+archive> > > Unfortunately, I'm still working on a >> few things: >> 1. Generating the correct diff from the upstream package. >> > > What exactly do you mean by "generating the correct diff". If you are > using dpkg-buildpackage, debuild or something like this the diff.gz and > the *.dsc file which belong to the orig.tar.gz source will be generated > automatically. > Am using debuild, but was unhappy about it (especially as the staden build scripts/makefiles seem to touch a few of the binary files and caused debuild to have an ascii text explosion on screen). I'd actually rather prefer to keep the debian/ directory somewhere separate with the patches therein, as then I can merely chuck the thing into a source control somewhere and let others play around with it as well. At the moment, the work I've done (changes, etc) are not in any source control, and I am loathe to put it into bazaar on launchpad; I was thinking about simply putting it onto sourceforge for now or, if debian-med could oblige with a walled-off area within their svn rep (so that I can't write elsewhere within debian-med) I'd gladly put it there. > > Or are you rather refering to the diffs you are creating in the debian/ > packaging directory by using tools like dpatch or quilt. In the Debian > Med team we have a slight preference of quilt. > I have to say, having never used quilt but having fought somewhat with debuild, I myself am inclined to try quilt :-) <snipped> > > http://debian-med.alioth.debian.org/docs/policy.html > > might be helpful. Thanks, that was helpful. > > 2. Fixing AMD64 breakages. >> > > I'd suggest reporting these problems upstream. I have learned that > upstream is quite responsive and is definitely interested in problems > concerning AMD64. > The breakages I have are on launchpad - the build process does not use the correct flags for AMD if AMD is detected. Since upstream for staden requires the builder to manually edit files if they are building for AMD, upstream considers this a partially solved problem. My changes to upstream sources in this regard was to add in an automatic detection and change the flags. Unfortunately, this hasn't worked (yet), but I am certainly very persistent and have no doubt that I'd get this working sooner rather than later. > > 3. Generating a seperate staden-doc package. >> > > This would be easy once you provide the URL to your work. We have > a lot of examples you can follow. You might also consider using our > common packaging SVN. If you check in your work we could easily add > things you feel not able to do yourself. This has turned out quite > effective in the past. > Thanks, this would be appreciated; who should I contact about this? > > 4. Generating a .profile just for ubuntu so that the default .profile >> is not needed. >> > > This seems to be a Staden specific .profile, right? I have to admit > that I did not yet dived into Staden deeply enough to comment on this. > If it is something about configuration it should be moved to > /etc/staden/profile - but this is just a wild guess for the moment. > (Perhaps some staden experts can chime in here) Or even /etc/staden.profile. However, currently the staden build process uses a profile for building, and then copies that very same profile over to the final destination to be used by the user. Without the profile, staden apps refuse to run (not in path) and libraries cannot be found (library path is different). Staden is different from most other *nix packages, in that nothing goes into /usr/bin or /usr/lib, etc . Instead everything goes into a 'staden' dir which has it's own 'bin', 'lib', etc. This is why the profile script has to be sourced before any staden program is run - the script sets path and library search paths, etc that staden needs. <snipped> If I remember right Staden needs io-lib and thus we tried to start with > io-lib first. We tried to separate this lib (well a lib means it is useful > for more than one application (not only Staden) and if I'm not missleaded > there are other applications just do so) to enable more flexibility and > avoid confusion between different versions of one lib in different > applications. > Moreover io-lib is a very bad name (I think upstream agreed to this). So > we added at least 'staden-' as prefix and tried to add a patch which > > svn:// > svn.debian.org/svn/debian-med/trunk/packages/staden-io-lib/trunk/debian > I've checked this out - I'm not sure which version of io-lib I should patch with this, but it looks good - neat and thorough :-) > Once this is done we wanted to proceed with Staden. So far for a short > explanation of our strategy. If you think you see a better way to > get Staden packaged this is fine as well. > All humans think they have a better way, why should I be any different ;-) But to be serious, though, my intention behind the packaging was to first package the large monolithic ball of code that is staden and make sure it works the way the users expect it to. Thereafter, I intended to slowly strip out the libraries into packages of their own (like IO-lib) and ensure that with each change staden is still working like it is expected to. To accomplish this, I will need a test suite (even if I have to write it myself, which I'd rather not) so that I can follow a cycle resembling this: 1. Build staden .deb 2. Generate test-results by running automated test-suite 3. Store test-results in source control 4. Make library independendent (remove it from staden) or make whatever other changes I want to to either staden or .deb 5. Rebuild staden and libraries 6. Re-run test-suite and diff the results with the test-results from source control. 7. GOTO 4 For now, I just want to ensure that what I did works (it compiles, and seems to work, but I need staden users to tell me this) before I start any ambitious plans. Finally, thank you all for bearing with me through my rather verbose ramblings, your help and advice is very much appreciated, especially if it seems like I'm stumbling about in the dark. Kind Regards Lelanthran
