[ITA] inetutils-1.5-1

[Charles Wilson]

Dr. Volker Zell wrote:
> 
> make[2]: Entering directory `/misc/src/inetutils-1.5-2/build/talkd'
> if gcc -DHAVE_CONFIG_H -I. -I/misc/src/inetutils-1.5-2/src/inetutils-1.5/talkd -I.. -I/misc/src/inetutils-1.5-2/src/inetutils-1.5/headers -I/misc/src/inetutils-1.5-2/src/inetutils-1.5/lib -I../lib -I/misc/src/inetutils-1.5-2/src/inetutils-1.5/libinetutils     -O2 -pipe  -DNCURSES_STATIC -MT acl.o -MD -MP -MF ".deps/acl.Tpo" -c -o acl.o /misc/src/inetutils-1.5-2/src/inetutils-1.5/talkd/acl.c; \
>         then mv -f ".deps/acl.Tpo" ".deps/acl.Po"; else rm -f ".deps/acl.Tpo"; exit 1; fi
> if gcc -DHAVE_CONFIG_H -I. -I/misc/src/inetutils-1.5-2/src/inetutils-1.5/talkd -I.. -I/misc/src/inetutils-1.5-2/src/inetutils-1.5/headers -I/misc/src/inetutils-1.5-2/src/inetutils-1.5/lib -I../lib -I/misc/src/inetutils-1.5-2/src/inetutils-1.5/libinetutils     -O2 -pipe  -DNCURSES_STATIC -MT announce.o -MD -MP -MF ".deps/announce.Tpo" -c -o announce.o /misc/src/inetutils-1.5-2/src/inetutils-1.5/talkd/announce.c; \
>         then mv -f ".deps/announce.Tpo" ".deps/announce.Po"; else rm -f ".deps/announce.Tpo"; exit 1; fi
> In file included from In file included from /misc/src/inetutils-1.5-2/src/inetutils-1.5/talkd/acl.c/misc/src/inetutils-1.5-2/src/inetutils-1.5/talkd/announce.c:20:
> /misc/src/inetutils-1.5-2/src/inetutils-1.5/talkd/intalkd.h::20:
> /misc/src/inetutils-1.5-2/src/inetutils-1.5/talkd/intalkd.h:3333:35: :protocols/osockaddr.h35: protocols/osockaddr.h: No such file or directory
> : No such file or directory
> In file included from /misc/src/inetutils-1.5-2/src/inetutils-1.5/talkd/intalkd.h:36,
>                  from /misc/src/inetutils-1.5-2/src/inetutils-1.5/talkd/announce.c:20:
> /usr/include/protocols/talkd.h:73: error: field `addr' has incomplete type
> In file included from /misc/src/inetutils-1.5-2/src/inetutils-1.5/talkd/intalkd.h:36,
>                  from /misc/src/inetutils-1.5-2/src/inetutils-1.5/talkd/acl.c:20:
> /usr/include/protocols/talkd.h:73: error: field `addr' has incomplete type
> /usr/include/protocols/talkd.h:74: error: field `ctl_addr' has incomplete type
> /usr/include/protocols/talkd.h:74: error: field `ctl_addr' has incomplete type/usr/include/protocols/talkd.h:92: error: field `addr' has incomplete type
> 
> /usr/include/protocols/talkd.h:92: error: field `addr' has incomplete type
> make[2]: *** [acl.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[2]: *** [announce.o] Error 1
> make[2]: Leaving directory `/misc/src/inetutils-1.5-2/build/talkd'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/misc/src/inetutils-1.5-2/build'
> make: *** [all] Error 2
> *** ERROR: make failed
> 

Yet another instance of using a custom cygport function. I'm going to 
consider this a WONTFIX in the packaging. The relevant cygport patch is 
attached, and once (if) appropriate support is added to the official 
cygport product, I will adapt inetutils.cygport to use it. Until then...



Based on my original 01/2007 proposal for various hooks (two "prep" 
hooks and two "install" hooks), Yaakov added the following to 
cygport-0.3.8-1 last month:

         # src_unpack_hook() is an optional function which can be defined
         # to alter the original source tree and avoid large patches
         # or long DIFF_EXCLUDES, or to apply patches in tarballs

However, of the four hooks I originally proposed, this is the only one 
merged into 0.3.8-1.  Of course, even that was a re-write of my original 
proposal. Sigh. [*]

So, I reworked my patch again, renamed the functions and implementation 
to mimic the new style and using the new 
__check_unstable/CYGPORT_USE_UNSTABLE_API support.  So, there remained 
three hooks, implemented in the attached patch.

src_unpack_post_hook()
src_prepinstalldirs_hook()
src_postinst_hook()

inetutils.cygport uses src_unpack_post_hook().

It appears that in recent CVS HEAD of cygport, something similar to 
src_unpack_post_hook() has been merged.  It's called src_patch_hook(), 
but is not exactly equivalent to src_unpack_post_hook().

Yaakov's src_patch_hook() is called after SRC_PATCH patches (think 
non-cyg-specific "official" patches) have been applied to the 
"origsrcdir" directory, but before the "working" src ${S} directory has 
been mirrored and (obviously) before the .src.patch and .cygwin.patch 
patches have been applied to it.

My src_unpack_post_hook() is called as the absolute last step in __prep, 
after ALL of those things are done.

Yaakov's version does not allow me to do any manipulations of files 
created by .src.patch or .cygwin.patch (such as add +x permission to 
scripts created by .cygwin.patch).  On the other hand, my version 
requires matching changes in both ${oldsrcdir} and ${S} -- otherwise bad 
diffs will be created.  (See the matching "ln -s" stuff below.)

In this particular case, I wanted to avoid multiple -- possibly 
divergent -- copies of the "extra" headers, so I used symlinks all 
around to 'real' files in CYGWIN-PATCHES. This can't be done before the 
.cygwin.patch is applied, because (a) these files and CYGWIN-PATCHES 
itself are created by applying the .cygwin.patch, and (b) these files 
and CYGWIN-PATCHES only exist in the ${S} directory, not the 
${origsrcdir}, so the relative paths will be different.  You could 
create dangling symlinks, knowing that .cygwin.patch will eventually 
"undangle" them, but you can't do that before the ${S} directory is 
created/mirrored from ${origsrcdir} -- if you did, then the (dangling) 
symlinks created in ${origsrcdir} will be copied over to the ${S} as-is: 
with the incorrect relative path to CYGWIN-PATCHES/real-header-file. And 
deliberately creating dangling symlinks is just plain icky.

There are other ways I could have approached this -- mainly by migrating 
the cygwin-specific header and script files out of CYGWIN-PATCHES and 
putting them into the "main" src area directly; in this way they would 
appear in the .src.patch, instead of the .cygwin.patch.  But that's not 
the way I wanted to organize the changes -- and I oughta be in charge of 
such things, not my tools.

(Even if I did it that way, I still would not be able to chmod +x during 
the prep phase the scripts created by .src.patch/.cygwin.patch, but that 
chmodding could be deferred to the install phase. Who would want to test 
config-* scripts in place, on the originals?  You should test the 
private installed copies in ../inst/usr/bin, so that your changes all 
get clobbered the next time you do a cygport install and forgot to copy 
the ../inst/ versions back to CYGWIN-PATCHES, right?  Or you should just 
manually chmod them if you want to test them in place -- what has 
automation ever done for anybody?) </sarc>

[*] On the plus side, something similar to my multiple-postinstall patch 
has been merged into CVS HEAD recently. It doesn't allow "foo.sh" to 
represent the postinstall script for the main foo package (it 'only' 
allows "foo.postinstall" and "postinstall.sh" for the main foo package), 
but Yaakov's code is much easier to follow (that 'foo.sh' concession to 
old g-b-s behavior made the code a LOT uglier...I'm not sorry to see it 
go, and am ecstatic to see sufficient support for per-subpackage 
postinstall/preremove scripts in cygport at last)

--
Chuck



export CYGPORT_USE_UNSTABLE_API=1

src_unpack_post_hook() {
         cd ${origsrcdir}/${SRC_DIR}
         mkdir -p headers/arpa headers/protocols
         (cd headers/arpa      && ln -s 
../../../../src/${SRC_DIR}/CYGWIN-PATCHES/arpa/tftp.h .)
         (cd headers/protocols && ln -s 
../../../../src/${SRC_DIR}/CYGWIN-PATCHES/protocols/talkd.h .)
         (cd headers/protocols && ln -s 
../../../../src/${SRC_DIR}/CYGWIN-PATCHES/protocols/osockaddr.h .)
         cd ${S}
         mkdir -p headers/arpa headers/protocols
         (cd headers/arpa      && ln -s ../../CYGWIN-PATCHES/arpa/tftp.h .)
         (cd headers/protocols && ln -s 
../../CYGWIN-PATCHES/protocols/talkd.h .)
         (cd headers/protocols && ln -s 
../../CYGWIN-PATCHES/protocols/osockaddr.h .)
         chmod +x ${C}/iu-config
         chmod +x ${C}/syslogd-config
}


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cygport-hooks.patch
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20080306/a4817f8b/attachment.ksh>