[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [MoM] Packaging fis-get



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

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

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.

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

-- 
http://fam-tille.de


Reply to: