Re: [MoM] Packaging fis-get
On 01/23/2012 03:09 AM, Andreas Tille wrote:
On Sun, Jan 22, 2012 at 06:12:34PM -0500, Luis Ibanez wrote:
...
The .tar.gz file is placed in the parent directory at:
debian-med/trunk/packages/fis-gtm/fis-gtm-initial
with name:
fis-gtm-initial_54002B.orig.tar.gz
Fine so far.
5) Expanded it with command:
tar -xzf *.orig.tar.gz
and now get two new files at:
debian-med/trunk/packages/fis-gtm/fis-gtm-initial/fis-gtm-initial
with names:
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"
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.
Yes, this is correct. Please remind: This is a really far from normal
package. Having tar.gz files inside a Debian orig.tar.gz file is
possible (I'm sure the X packages formerly were packaged like this, to
lazy to check whether this is the case today - you can verify by
apt-get source xorg
if you are interested). So usually you will find unpacked source files.
At least this is what Thorsten previosely did. He seems to be on VAC
because he did not yet stepped into this discussion so we need to fight
our way to his decisions on our own. In case we would consider this as
not helpful in the end we can change whatever is needed.
inspected both with tar -tzf
and since none of them
is creating its own directory yet,
I created directories with their names.
The idea is not bad, but the packaging is intended to leave the files
as they are.
6) Created directories:
mkdir gtm_V54002B_linux_i686_pro-i386
mkdir gtm_V54002B_linux_x8664_pro-amd64
So this was a step which is not helpful for the current packaging.
However, once we are talking about those archives I have a question to
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.
What we can do for the Debian orig.tar.gz when we are creating this
file anyway in the get-orig-source script is the following:
1. unpack the tarballs
2. remove *.o files (and other possibly unneeded binaries
3. move files which are *specific* for the different architectures
to directories named like bin-i386 resp. bin-amd64 (or something
like this
4. move files which are common to both architectures to a directory
common (*.m, *.h, *.gtc, shell scripts, *.hlp, etc.)
BTW, I also found *.csh files: After inspecting some of these
they could be probably ported to POSIX shell which would enable
us sparing a useless csh (clone) dependency. There is no point
in forcing an unneeded shell as a dependency upon the user
If you consider this plan a good idea your task would be the following:
Change get-orig-source so that the resulting
fis-gtm-initial_54002B.orig.tar.gz will have the following layout:
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.
[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.
Regards
-- Bhaskar
7) Entered the directory of the i386 version
and expanded in there the corresponding
.tar.gz file from the parent directory:
cd gtm_V54002B_linux_i686_pro-i386
tar -xzf ../gtm_V54002B_linux_i686_pro-i386.tar.gz
8) Copy in this code the content of
the "debian" directory.
cp -a ../../trunk/debian/ .
9) Continued with Path (B) instructions
and called "debuild" in that same
directory:
debian-med/trunk/packages/fis-gtm/fis-gtm-initial/fis-gtm-initial/gtm_V54002B_linux_i686_pro-i386
typed the command:
debuild
that returned the message:
This package has a Debian revision number but there does not seem to be
an appropriate original tar file or .orig directory in the parent directory;
(expected one of fis-gtm-initial_54002B.orig.tar.gz,
fis-gtm-initial_54002B.orig.tar.bz2,
fis-gtm-initial_54002B.orig.tar.lzma or gtm_V54002B_linux_i686_pro-i386.orig)
continue anyway? (y/n) n
Considering your step 6) which I explained in detail steps 7) - 9) can
not succeed. I's advise to follow the original path of Thomas just for
the sake to get some kind of a deb first before fiddling around with
get-orig-source. You current directory layout after copying the debian/
dir should look like this:
$ ls -l fis-gtm-initial
insgesamt 19840
drwxr-sr-x 4 tillea admin 4096 Jan 22 22:57 debian
-rw-r--r-- 1 tillea admin 10024159 Jan 22 14:58 gtm_V54002B_linux_i686_pro-i386.tar.gz
-rw-r--r-- 1 tillea admin 10251995 Jan 22 14:58 gtm_V54002B_linux_x8664_pro-amd64.tar.gz
10) Now go back to instructions on how to
fix the name of the expected version by
...
and attempt to do "debuild" again.
That's OK.
This time I get:
dpkg-buildpackage -rfakeroot -D -us -uc
dpkg-buildpackage: set CFLAGS to default value: -g -O2
dpkg-buildpackage: set CPPFLAGS to default value:
dpkg-buildpackage: set LDFLAGS to default value: -Wl,-Bsymbolic-functions
dpkg-buildpackage: set FFLAGS to default value: -g -O2
dpkg-buildpackage: set CXXFLAGS to default value: -g -O2
dpkg-buildpackage: source package fis-gtm-initial
dpkg-buildpackage: source version 54002B-1
dpkg-buildpackage: source changed by Andreas Tille<tille@debian.org>
dpkg-buildpackage: host architecture amd64
dpkg-checkbuilddeps: Unmet build dependencies: debhelper (>= 8)
dpkg-buildpackage: warning: Build dependencies/conflicts unsatisfied; aborting.
dpkg-buildpackage: warning: (Use -d flag to override.)
debuild: fatal error at line 1340:
dpkg-buildpackage -rfakeroot -D -us -uc failed
That looks more promising... :-)
Yes. :-) Dominique just answered your question (nice to see that others
read your mails as well - you see the profit of writing to the mailing
list, right?
It seems to be lacking "debhelper"
Version: 7.4.15ubuntu1
(I'm doing all this in a Ubuntu 10.04 LTS - Lucid Lynx )
Since "debuild" claims to need version>= 8,
it looks like it is time to try the same sequence
of steps in a more recent installation.
As Dominique said you either can simply step back in the debhelper
version. Alternatively it might be that there might be a backported
debhelper 8 available - I'm sorry, I never used Ubuntu and are just wild
guessing. Whether it is a good idea to keep on testing on Ubuntu or not
is hard to say. For the final upload you need a Debian unstable chroot
anyway so becoming comfortable with this is heavily recommended.
However, it might make sense to some extend to redo all your steps under
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'm no heading to boot a VM
where I recently installed Ubuntu 11...
This does have debhelper 8, right? As I said: I personally can not help
much if it comes to Ubuntu specific problems. I hope these will be not
to many, but you might face situations when you need to ask for help at
other places. It would be great to have a result which builds unchanged
on Debian as well as on Ubuntu.
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.
Reply to: