Re: [MinGW-dvlpr] mingw-get feature request

[Keith M. <kei...@us...>]

On 26/08/11 22:19, Charles Wilson wrote:
>> Okay.  I'm going to implement mingw-get such that it will:
>> 
>>   - download source tarballs to $APPROOT/var/cache/mingw-get/source
>>   - unpack ONE tarball level, placing the resultant tree in $PWD
>> 
>> If you can adapt to that, fine.
> 
> Perfect.  <not a complaint>It may cause some issues with -src
> packages that use Cesar's msysrlsbld/pkgbuild scripts, but we can
> address those by modifying those packages on as as-needed, 
> normal-course-of-development basis.  There aren't many of them.
> </not a complaint>

Okay.  I've now committed a tentative implementation of this to CVS; it
implements both 'mingw-get source ...' and 'mingw-get licence ...'
requests, (but not yet any "build-requires" capability).

Both of these new requests operate as described above, (except that
"licence" will shepherd downloaded "-lic" tarballs into the normal
package cache directory, $APPROOT/var/cache/mingw-get/packages); in both
cases, the downloaded tarball will be unpacked in $PWD, with nothing
being "installed" in the associated $SYSROOT directories.

As with the "install" request, you may use the "--print-uris" option to
suppress downloading and "installing" (i.e. unpacking), while reporting
the URI whence the package would be downloaded; alternatively, you may
use the "--download-only" option to achieve the download, (into the
appropriate cache directory), while suppressing installation/unpacking.
(Note that both of these options now imply "--reinstall", to ensure that
the request is honoured, regardless of the installation status of the
associated binary package).

In addition to the preceding two options, you may also use the new
"--all-related" option, to apply the request recursively, processing the
source/licence tarballs for all auxiliary packages which are needed to
satisfy the runtime requirements of the associated binary package, in
addition to those of the package specified on the command line.

I'm reluctant to roll out an immediate release, because my own testing
has revealed a weakness in our mingw-dist manifests; specifically:

  <source tarname="foo-%-msys-%-src.tar" />

is not sufficiently deterministic to identify the name of the source
tarball -- the compression type is indeterminate.  Likewise for:

  <licence tarname="foo-%-msys-%-lic.tar" />

I think we should fix this, before progressing a roll out.  I don't like
the idea of an heuristic bodge, to guess a missing compression type, so
we may either include it explicitly, e.g.:

  <source tarname="foo-%-msys-%-src.tar.lzma" />
  <licence tarname="foo-%-msys-%-lic.tar.lzma" />

or we may exploit an extension I've added to the template substitution
code, allowing inheritance of the same type as the associated binary:

  <source tarname="foo-%-msys-%-src.tar.%" />
  <licence tarname="foo-%-msys-%-lic.tar.%" />

or even:

  <source tarname="foo-%-msys-%-src.%" />
  <licence tarname="foo-%-msys-%-lic.%" />

to inherit the entire "tar.lzma", or whatever.

Finally, in addition to this compression type mapping issue, I've also
identified an anomaly specific to the msys-core package specification;
the tarname:

  msysCORE-1.0.17-1-msys-1.0.17-bin.tar.lzma

conveys no canonical relationship to the package name, msys-core.  (This
affects the implementation, which I've also added to CVS, of the
capability to anonymously upgrade all installed packages).  The easiest
work around for this is to add an alias:

  <package name="msys-core" alias="msysCORE">

so, while the anonymous upgrade capability deserves its own separate
discussion thread, it may be expedient to address both issues at the
same time.

-- 
Regards,
Keith.