Re: [MoM] Packaging fis-get
On Mon, Jan 23, 2012 at 11:22:47AM -0500, Bhaskar, K.S wrote:
>
> >>gtm_V54002B_linux_i686_pro-i386.tar.gz
> >>gtm_V54002B_linux_x8664_pro-amd64.tar.gz
> [KSB] These look like binary distributions. For what it's worth,
> the GT.M distribution files have names of the form:
>
> gtm_<ver>_<os>_<arch>_<pkg>.tar.gz
>
> where
>
> <ver> is an abbreviated form of the version number, e.g., V54002B is
> short for V5.4-002B
> <os> is the operating system, in this case, linux
> <arch> is the architecture, in this case i686 or x8664
> <pkg> is can be "src", "pro", "bta" or "dbg"
Many thanks for the explanation. Considering this I think we should
change the proposed version numbering used by Thorsten and use rather
fis-gtm-initial (5.4-002B-1) UNRELEASED; urgency=low
in debian/changelog. However, this requires a
opts="dversionmangle=s/[.-]//g" \
in debian/watch prepending the download line. But be careful - this
also needs a rewrite of debian/get-orig-source. In case Luis might be
bored by the other tasks he might like to write such a script to learn
how watch / uscan / get-orig-source are playing together. I would have
written the get-orig-source a bit differently than Thorsten and for the
needed change of the version number (different in the Debian version
string than in the downloaded file) for my personal feeling this becomes
more complex the way it is now. If you (Luis) want to have a look
into another example which is also downloading more than one archive
this link might be helpful:
http://anonscm.debian.org/viewvc/debian-med/trunk/packages/sofa-framework/trunk/debian/get-orig-source?view=markup
The thing is that I realised that both things are working at the same
time:
uscan --verbose --force-download
as well as
make -f debian/rules get-orig-source
I'd call this task optional for the MoM effort. While you can learn a
lot I think for our final goal it is more helpful if you work for now
with the current versioning and solve the other open issues here and I
will have a look into get-orig-source at some point in time. There is
no point in distracting you from tasks you can do better than me.
> Note that <os> and <arch> are names from GT.M, e.g., even though
> Debian calls the 64 bit x86 architecture amd64, GT.M refers to it as
> x8664. Also, "src" is a source distribution, and even though the
> source tarball identifies itself as i686, the same source code
> builds both 32- and 64-bit binary distributions. "pro" is short for
> production, and the normal binary distribution. "dbg" is a binary
> distribution for debugging - it has asserts turned on, which means
> that under certain conditions processes will terminate with an
> assert instead of running code to try to recover from the internal
> inconsistency. "bta" is in between "pro" and "dbg" but we don't use
> bta builds any more in the development group.
If I try to summarise: For the moment (=the bootstrapping) the pro
packages are the correct ones. The architecture issue was solved by
using
dpkg-architecture -qDEB_BUILD_ARCH
in debian/rules which I used to pick the right tarball (we definitely do
not need both in the *.deb (see my commits from yesterday).
> >you with your upstream hat on: What is the sense to provide a lot of
> >*.o files inside these tarballs? As far as I know you need a running
> >mumps as an initial step and I see some binaries starting with mu*
> >inside the tarball. However, the *.o files are looking pretty useless
> >to me. If my suspicion that these are simply leftovers from compile
> >process and not really needed it would be helpful if these could be
> >stripped from the upstream tarball (perhaps in the same effort when
> >creating non-dirty directories).
> [KSB] GT.M has a compiler for the M/MUMPS language. The compiler
> takes source code in .m files and generates object code in .o files.
> The GT.M runtime system dynamically loads these .o files on demand
> in all architectures. On the 64-bit architecture, the .o files can
> also be placed in shared libraries with ld, but not on the 32-bit
> architecture.
>
> A GT.M binary distribution contains some utility programs
> distributed as source code (.m files) and the installation script
> (named configure) compiles these as part of the installation
> process.
>
> There are also binary files (GDE*.o files) whose source code is not
> included in the binary distributions. This is because the GDE
> program considered an executable program that is part of GT.M,
> except that it is written in M and not in C, as the other
> executables are. Of course, all source code is in the source
> tarball.
So I'll leave the decision what to move to the *.deb to Luis and trust
he es working according to the rule to only take over what is really
needed for the bootstrapping process. If just using the complete
archive is the cheapest solution to reach our goal that's fine.
If I would be in Luis' shoes I would probably not use the tarball
itself but untar it to
/var/lib/fis-gtm/initial
(or similar) to really only do something in postinst on the target
installation machine.
> [KSB] Note that there are (at least!) two strategies to creating a
> GT.M distribution.
>
> The first is to build a standard GT.M tarball, and to create a
> wrapper for it. The wrapper would unpack the tarball in a temporary
> directory, and run the configure script provided by GT.M to install
> the binary distribution in standard locations. If you look at the
> gtminstall script in the tarball (and separately at http://sourceforge.net/projects/fis-gtm/files/GT.M%20Installer/v0.11/gtminstall),
> it is an attempt to create such a wrapper. gtminstall is still a
> bit of a work in process. This may be an easier approach.
>
> The second is to create an installer that does not use the configure
> script at all. This is a purer approach, but probably more work.
I'd vote in any case for the option causing less work for the initial
packaging which is needed for the bootstrapping process. Once we are
talking about the real production package we might reconsider this
decision if needed.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: