This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygport-0.9.3 in release-2


Yaakov (Cygwin Ports) wrote:
> Charles Wilson wrote:
>> a) my example, ncurses, has a LOT (50 or so) "official" patches
>> b) they are all gz-compressed; cygport might not support compressed
>> patches in PATCH_URI
> 
> Compressed single patches are supported in PATCH_URI since 0.3.5.

Good to know. I /thought/ that was the case, but was too lazy to check
while composing the email.

>> So, in fact, for ncurses (where some of the official upstream "patches"
>> are actually shell scripts with shar-compressed patches!) I actually
>> DON'T specify these files in PATCH_URI. Instead, I specify them in
>> SRC_URI, and then use src_unpack_hook to apply (that is, execute!) them.
> 
> Interesting, I'd like to see those "patches"; with the recent release of
> ncurses-5.7, all the 5.6 patches are gone.

They were called "rollup" patches. T.E.D. releases patches roughly every
week, and then every month (or two, or three), he combines all patches
dating back to an official release into a "rollup" patch -- and these
"rollup" patches are in the shar-archive-auto-apply format.  You can see
an example in the current cygwin ncurses-5.5 package (yes, two years
old. I know...)  T.E.D. also provides the patches to update a 5.x tree
to 5.x+1 in that form:

ftp://invisible-island.net/ncurses/patches/

> I think you know that I haven't been a big fan of this idea.
> Nevertheless, cygport 0.9.x allows you to call src_compile(),
> src_install(), or any self-defined function on the command line, but it
> doesn't allow for any arguments to the function.  Adding that limitation
> made the implementation much easier than what you were proposing, and I
> hope that it will be sufficient.

Yes, that will do.

If one really needs to pass arguments -- which I (usually) don't --
there are a number of workarounds:
  1. export MY_FUNC_ARGS=("a b" c "d e"); cygport foo.cygport my_func
     where my_func() processes MY_FUNC_ARGS[@] (which in this
     case has three elements, "a b", c, and "d e").
  2. You could do something similar with response files
  3. Reduce granularity and then have a few specific functions.
     For instance, rather than:
       cygport cvs.cygport custom1-run_test N
     where N is any number from 1 to 300, instead do
       cygport cvs.cygport run_test_group1
       cygport cvs.cygport run_test_group2
       cygport cvs.cygport run_test_group3
       cygport cvs.cygport run_test_group4
     where each group comprises 75 or so tests.
I'd probably lean to #1. If it ever came up.

In any event, all of those workarounds can be implemented solely inside
a specific .cygport file, without any additional (or intrusive, or
ugly-as-sin) changes to /usr/bin/cygport.

The custom- stuff is a marvelous (ab)use of bash, though, ain't it?

That leaves only:
  cvs topdir support
  postinst hook support
  relocatable [*]

=====

[*] relocatable. I've ported those changes to 0.4.2, but...they are
really, just, wow.  Awesomely ugly. I've decided to drop them entirely,
for the following reasons:

1)
According to Bruno, "official" packages aren't supposed to be
relocatable. "I hope that people will learn when to use
--enable-relocatable by themselves. For example, I don't think a Linux
distributor should use --enable-relocatable for anything installed in
/usr - it would only be bloat that makes the system slower."

Since the relocatable magic applies only to libintl, gettext, (and my
personal patched versions of proj and libgeotiff) -- all of which I
maintain and which go into cygwin's /usr -- Bruno's argument against
--enable-relocatable applies.

2)
cygport is intended for use in packaging "official" cygwin stuff. Not
random compiled-with-wierd-options stuff. So, it doesn't really need to
support the rather esoteric --enable-relocatable, as official packages
aren't supposed to use that option (see 1).

3)
--enable-relocatable is a bad fit for cygport. As a consequence of
cygport's focus on "official packages only", it always installs into
/usr. It's sorta hard to force it into installing to
/tmp/cygport-reloc-au723g/ -- the whole --enable-relocatable scheme
relies on using such odd, random, never-repeated, --prefixes.

4)
The only reason I was even bothering was to help iron out the bugs in
Bruno's reloc support.  Well, as of 0.17, it needed almost ZERO
additional effort from me to make it work (a single two-line patch --
and THAT was actually gnulib's fault, not Bruno's reloc stuff). I think
that qualifies as "good enough" and I can, in the future, test reloc
support "normally" -- that is, configure/make/install sans-cygport.

5)
Ye GODS, the patch is ugly. I'll post it for historical interest,
but...yuck!

=====

FWIW, here's the current ncurses prep function (eventually to become
src_unpack_hook when I release 5.7). ${PF}.extra.patch is a separate
patch (of mine) that I wanted to keep separate from .src.patch.

SRC_URI="mirror://gnu/ncurses/${PN}-${PV}.tar.gz \
ftp://invisible-island.net/${PN}/${PV}/${PN}-${PV}-20060909-patch.sh.bz2 \
ftp://invisible-island.net/${PN}/${PV}/${PN}-${PV}-20060916.patch.gz \
ftp://invisible-island.net/${PN}/${PV}/${PN}-${PV}-20060923.patch.gz \
ftp://invisible-island.net/${PN}/${PV}/${PN}-${PV}-20060930.patch.gz \
ftp://invisible-island.net/${PN}/${PV}/${PN}-${PV}-20061007.patch.gz \
ftp://invisible-island.net/${PN}/${PV}/${PN}-${PV}-20061014.patch.gz \
ftp://invisible-island.net/${PN}/${PV}/${PN}-${PV}-20061021.patch.gz \
ftp://invisible-island.net/${PN}/${PV}/${PN}-${PV}-20061028.patch.gz \
ftp://invisible-island.net/${PN}/${PV}/${PN}-${PV}-20061104.patch.gz \
${PF}.extra.patch"

src_prep_init_hook() {
  local -i n=1
  local -a mySrcURI=($SRC_URI)
  local breakout=""
  local pnz
  local pn
  local msg

  cd ${origsrcdir}/${SRC_DIR}

  # This "loop" is only executed once (at most). We
  # use 'while' instead of 'if' because it is a more
  # flexible control flow structure.
  while [ ${n} -lt ${#mySrcURI[*]} -a -z "${breakout}" ]
  do
    breakout="yes"
    pnz=${mySrcURI[${n}]##*/}
    case "${pnz}" in
    *.gz  ) pn=${pnz%.gz} ;;
    *.bz2 ) pn=${pnz%.bz2} ;;
    *     ) pn=${pnz} ;;
    esac

    case "${pn}" in
    *.sh ) n+=1 ;;
    *    ) continue ;;
    esac

    if [ -f ${origsrcdir}/${pn} ]
    then
      inform "APPLYING OFFICIAL ROLLUP PATCH: ${pn}"
      ${origsrcdir}/${pn}
    else
      if [ -f ${origsrcdir}/${SRC_DIR}/${pn} ]
      then
        inform "APPLYING OFFICIAL ROLLUP PATCH: ${pn}"
        ${origsrcdir}/${SRC_DIR}/${pn}
      else
        warning "COULD NOT FIND OFFICIAL ROLLUP PATCH: ${pn}"
      fi
    fi
  done

  while [ ${n} -lt ${#mySrcURI[*]} ]
  do
    pnz=${mySrcURI[${n}]##*/}
    msg="OFFICIAL INCREMENTAL PATCH"
    case "${pnz}" in
    *.gz  ) pn=${pnz%.gz} ;;
    *.bz2 ) pn=${pnz%.bz2} ;;
    *.patch ) pn=${pnz} ; msg="CYGWIN SPECIAL PATCH" ;;
    * )
      warning "Skipping unknown file: ${pnz}"
      n+=1
      continue
      ;;
    esac

    if [ -f ${origsrcdir}/${pn} ]
    then
      inform "APPLYING ${msg}: ${pn}"
      apply_patch ${origsrcdir}/${pn}
    else
      if [ -f ${origsrcdir}/${SRC_DIR}/${pn} ]
      then
        inform "APPLYING ${msg}: ${pn}"
        apply_patch ${origsrcdir}/${SRC_DIR}/${pn}
      else
        warning "COULD NOT FIND ${msg}: ${pn}"
      fi
    fi
    n+=1
  done
}

--
Chuck




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]