Re: [MoM] Packaging fis-get

["Bhaskar, K.S" <ks.bhaskar@fisglobal.com>]

On 01/23/2012 03:32 PM, Andreas Tille wrote:
> Hi Luiz,
>
> On Mon, Jan 23, 2012 at 02:52:08PM -0500, Luis Ibanez wrote:
[KSB] <...snip...>
> 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.
> >   ...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)
> > >                   |
> > >                   +- common
> > >                   |
> > >                   +- bin-amd64
> > >                   |
> > >                   +- bin-i386
> > >
> > > 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]
> > > yesterday.
> >
> > 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.
> Good.
[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.

Regards
-- Bhaskar

> > 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.
>
> Kind regards
>
>           Andreas.

--
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.