Re: [MoM] Packaging fis-get
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.
> [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.
> 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.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: