Re: [MoM] Packaging fis-get
On 01/23/2012 03:32 PM, Andreas Tille wrote:
On Mon, Jan 23, 2012 at 02:52:08PM -0500, Luis Ibanez wrote:
If I understood Bhaskar correctly for amd64 *.o files can be linked to
*.so files but for i386 this is not possible (I admit that I fail to
understand why this should not be possible, but it seems I have to
trust Bashkar here).
[KSB] Even though both 32-bit and 64-bit GT.M for x86 are built from the
same source code, the GT.M code generators are a couple of generations
apart in design evolution. The code generator for 32-bit is perhaps the
most primitive version still in use and the 64-bit is one of the most
modern. The 32-bit code generator generates object code in an old format
(I think XCOFF). In both cases, the GT.M dynamic linker knows how to
dynamically link .o files, but only the 64-bit .o files are in a format
that ld understands, and only the 64-bit GT.M dynamic linker knows how to
link object modules in .so shared libraries.
[KSB] Although I am personally a bash user, the entire GT.M automation
infrastructure is build around tcsh (not even csh). It may be easier to
use tcsh for now and not try to convert the scripts till later.
...this is more of a philosophical question actually...
... I'm not sure if that will be better than carrying
prebuild .o files...
Well, I'm not against .o files. I'm against unneeded stuff and in all
previous cases when I dealt with *.o files these were just unused
leftovers when upstream had forgot to clean up the tarball. I guess I
will see more things when past experience is not easily applicable when
dealing with GT.M. So in short: *.o files need to be kept if they are
needed. BTW, we are diving more and more into upstream land and it is
rather you than me making the decisions.
Please remember: *YOU* are the maintainer of the package and my role
is to help solving Debian packaging problems. You should be bold and
there is no point in simply accepting whatever I do except if I give
really hard reasons based on written documents.
fis-gtm-initial-+ (optional fis-gtm-initial-54002B at your preference)
By doing so we get a more transparent tarball. However, this leads to
the consequence that the current packaging which explicitely relies on
the complete tarballs need to be changed. You need to tweak the install
target as well as changing the postinst file. IMHO the postinst file
does to much work anyway as I wrote in my other mail tagged [MoM]
Bhaskar suggests here to use the install scripts provided upstream.
I'm tempted to follow this route, and to encode this in the build rules,
unless this somehow contradict Debian packaging policies or practices...
I'd also recommend to follow Bhaskars suggestions. And no, there is no
real contradiction except what also Bhaskar considered a bad idea:
Temporary files do not belong to /usr/lib/fis-gtm.
I'm building a Debian VM right now,
and will retrace the steps in there.
It makes a lot of sense to do this in
a native Debian installation.
At least as we are in the beginning step in any case.
your target system (whatever it might be). Reducing the number of
dependencies (for instance getting rid of csh files of possible) might
make live easier.
I'll look at converting the csh scripts.
I'm now heading to have a Debian VM
and retracing the steps by the end of today.
I'm happy that we are making some progress step by step.
GT.M - Rock solid. Lightning fast. Secure. No compromises.
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.