Re: [MoM] Packaging fis-get

["Bhaskar, K.S" <ks.bhaskar@fisglobal.com>]

On 01/31/2012 04:16 PM, Andreas Tille wrote:

On Tue, Jan 31, 2012 at 01:40:22PM -0500, Bhaskar, K.S wrote:

I can not imagine that finding a way to create a "small number" (can you
give exact numbers please) should be that hard.  For instance if you
take the effort I took to dive from scratch into Java packaging to build
packages for several prerequisites of target programs to make them
finally distributable in main this was more than creating "some files"
by other means than they are usually created.

[KSB2] It's not hard, but since everything is produced by heavily
automated scripting, someone would have to do a small audit.  Not
hard, but we are trying to freeze the code for a major release.

Well, there would always be an excuse because of some certain release
status.  I was told that Debian packaging would be important for GT.M
and there is a community of about 3000 developers.  Could any of them
please give this a try?  You say "not hard" + "small audit" this does
not sound like it would occupy an interested developer in a way to be
considered a showstoper in a release cycle.

Perhaps you take it this way:  I constantly try to release some certain
packages and even though I try to spend a mentionable amount of my
available time in helping others and specifically helping Luis to enable
him working on the packaging which we can not do on our own for instance
we have no idea how to do such "small audits".  I have no idea whether
Luis is deep enough in the GT.M issues to know how to do the "not hard"
work but if someone from GT.M would provide him the needed information
this would really prove your interest to come foreward here.

[KSB3] Thanks for the encouragement, Andreas, and thanks for all your efforts.  Really.  We would not be here without your encouragement over the years.

[KSB2] Yes, as human readable source code - even if generated by a
script from a text file - it should be DFSG free.  But the devil's
advocate argument is that even if it is human readable C code, since
it is generated from a text file, is is not source code.  But if
that works for getting GT.M into the package, lets do it.

Ftpmaster is not a devil so we will not be confronted with these
arguments.  So I'm in all favour of doing this.
 

However, those files are not part of the upstream source tarball, so
to get the files today, you have to build GT.M once.  Once you build
GT.M once, the files are there and the bootstrap is accomplished.

I try to rephrase my suggestion.

   1. Download a GT.M source distribution as orig.tar.gz
   2. Download the missing but needed autogenerated C files
      and add them as patch set (with dpkg source format 3.0 you
      can even have two source tarballs, but that's a detail)

Build the package from the files exclusively without needing a running
GT.M.

[KSB3]  It could work with a slight difference.

• Download the original GT.M source tarball on a system that has a GT.M binary.  Follow the instructions in the README to build GT.M on a machine that has GT.M.
• Use something like diff to compare the original tarball with the new tarball and find the C files generated by the build process.
• Create a new source tarball of the original files plus the new files and move it to a machine without GT.M (or just on the same machine, but don't set the environment variable that points to the existing GT.M).  Comment out the part of the shell script that generates the new C source files and build GT.M.

Once we get the release out, I'll see about releasing an updated
source tarball with the generated files.  But that is a few weeks
out at best.

I do not know whether you follow a date based release cycle.  In Debian
terms like "a few weeks" frequently turn out to be "a few monthes".  If
this might happen with GT.M we will miss the freeze for the next Debian
stable release which will in turn mean another two years no GT.M in
Debian.

On the other hand if we follow the plan I layed out above with *any*
currently available GT.M release we have a fair chance to build your
upcoming release with an at this time in Debian existing fis-gtm package
and by good coincidence your new release will end up in the next Debian
stable release.

According to my experience this is the *only* fair chance to get GT.M
into Debian in a reasonable time frame.  So if you or some other GT.M
developer would put the needed files next to the source tarball in the
download area I could try to follow together with Luis the new strategy.
This will take us long enough - so please pretty please give us the
code we need to start working instead of spending time in discussing.

[KSB3] In theory we are date driven, like Ubuntu rather than criteria driven like Debian.  In practice, since we have release gating criteria without which we will not release GT.M (because of the applications that use it) releases are a hybrid.  We have a code freeze scheduled for this Friday, February 3 and a release for mid February.  I think the odds are better than 50% that we will make it, and the odds are close to 90% of freezing by February 10.

I will see what I can do about providing the additional C files before the release, but no promises.

-- Bhaskar

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.