On Tue, Nov 4, 2008 at 12:20 PM, Andreas Tille
<tillea@rki.de> 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.
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.