Re: [MoM] Packaging fis-get
On Mon, Jan 23, 2012 at 02:52:08PM -0500, Luis Ibanez wrote:
> >From his clarification, it looks like the .o files are required, given
> that they are actually produced by a GTM compiler. So we are
> trapped in a chicken-egg situation where we need to bootstrap
> the build process....
> Although this makes me wonder on how different this is from
> building GCC,...that is, to compile GCC, we need a functional
> GCC compiler in that build machine.
It is not different at all - that's actually the most apropriate
comparison and was used in previous discussions as well.
> Wouldn't it make sense there to say that the machines building
> the fis-gtm package would have to have a functional GTM
> compiler installed ?
Yes, exactly this.
> and in that way we don't have to include
> the .o files in the tar.gz files...
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
> ...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.
> 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.