Re: [MoM] Packaging fis-get
Andreas,
On Mon, Jan 23, 2012 at 3:09 AM, Andreas Tille <andreas@an3as.eu> wrote:
>
> 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).
>
Bhaskar addressed this point in his email today at 11:22am (EST).
>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.
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 ? and in that way we don't have to include
the .o files in the tar.gz files...
...this is more of a philosophical question actually...
... I'm not sure if that will be better than carrying
prebuild .o files...
> 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.
>
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...
>
> 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.
Got it.
> 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
>
Perfect,
This is very useful for me to be sure
that I'm retracing your steps correctly.
>> 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?
>
Yes, very nice indeed.
I appreciate all the help.
>> 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.
>
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.
> 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'll look at converting the csh scripts.
>> 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.
>
Never mind about this Ubuntu-11 VM suggestion.
I'm now heading to have a Debian VM
and retracing the steps by the end of today.
Thanks
Luis
Reply to: