Re: [MinGW-dvlpr] Fwd: Tentative meta package manifests

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

On Friday 18 June 2010 01:48:01 you wrote:
> Keith,
>
> Could you comment on these meta-package .xml manifests?

I was hoping to find some time to play with them first, but I haven't 
been able to do that yet.

> Specifically, whether I've gotten the syntax right for "virtual"
> packages (and <requires /> elements ON virtual packages).
> http://comments.gmane.org/gmane.comp.gnu.mingw.devel/3852

The only difference, in terms of mingw-get processing, between a 
package with class="virtual" and a regular package, is that the 
virtual package has

  <download tarname="none" />

implicitly and irrevocably asserted for each and every one of its 
constituent component packages, if any, and each and every one of 
its/their contained releases; this is interpreted by the download 
function, as an indication that there is no archive to fetch, and by 
the installation function, that there is no archive to unpack.  Other 
than this, dependency resolution and installation tracking are 
performed identically, for both real and virtual packages.

> Also, the following worry cropped up.  Most of our mingw32
> subsystem packages are named like:
>
> 	xz-4.999.9beta_20100401-1-mingw32-bin.tar.bz2
> 	liblzma-4.999.9beta_20100401-1-mingw32-dll-1.tar.bz2
>
> that is, there is no subsystem version before the component type.
> However, I've been in the habit of representing dependencies on
> those packages as follows (taken from the mingw32-xz.xml manifest,
> all non-germane elements removed):
>
>     <package name="mingw32-xz" alias="xz">
>       <component class="bin">
>         <requires eq="mingw32-liblzma-%-mingw32-%-dll-1.tar" />
>       </component>
>       <licence tarname="xz-%-mingw32-%-lic.tar" />
>       <source tarname="xz-%-mingw32-%-src.tar" />
>     </package>

Yes, I'd noticed that you were doing this.  I haven't, in the mingw32 
manifests I've been preparing, but if I've got the coding right, then 
either style should work for as long as we continue to omit subsystem 
version tags on mingw32 packages; (I guess I should test this).

> Or, from mingw32-libarchive.xml (all non-germane elements removed):
>
>     <package name="mingw32-libarchive" alias="libarchive">
>       <component class="dll">
>         <requires eq="mingw32-liblzma-*-mingw32-*-dll-1.tar" />
>       </component>
>     </package>

Same in this case...

> Notice, in each case, the second '%' or '*'.  Should that be there,
> since there's nothing for it to match?

'*' should match anything at all, including an empty field, while '%' 
causes the corresponding field from the requirer's own tarname to be 
propagated into the required spec; if the requirer's field is empty, 
then nothing will be copied.

> I guess the question is, is the match string like a 'glob' -- in
> which case '*' can match "nothing" but that would leave two
> adjacent hyphens...a sequence that doesn't appear in any of our
> actual package names.
>
> Or is it just a "pkginfo resource specifier" in which case it is
> simply broken down into a set of field values, as is each candidate
> package name, and only the field values are compared. (e.g. the
> "hyphens" in both are actually discarded before the comparison is
> made).
>
> I suspect it is the latter,

It is.

> but I'm no great shakes with lexers, so 
> inspecting the code doesn't really tell me much.

All the lexer does is decompose the supplied tarname into an array of 
(char *) pointers, one for each of the line items you see when you 
run pkginfo.exe on the specified tarname.  The decomposition is 
performed on a strdup'd copy of the original tarname, and the 
returned pointers refer to their respective substrings within that; 
the intervening hyphens are replaced by NUL's, in passing.  The 
dependency resolver, and the version comparator, both of which use 
this array of pointers, are coded in C++ from the outset.

Now, addressing your original query:

> I'm pretty hazy on the correct syntax for meta/virtual packages, so
> I'm not ready to check these in just yet.  Instead, I'm posting
> them here for comments.
>
> There are 4.
>
> msys.xml
> ========
> the top level include-all-the-others manifest. Also defines the
> package-group-hierarchy.  Doesn't actually specify any packages of
> its own.

I see two issues here.  The first is trivial: the catalogue attribute 
specs in the package-list specs should omit the .xml extension because 
that is already incorporated in the URI template for the repository.

The second: I wonder if it is prudent to aggregate all of the separate 
package-list specs in this manner, might it not be more maintainable 
to specify appropriate subsets within msys-base.xml, msys-dtk.xml and 
msys-dvlpr.xml?  We certainly want to avoid multiple inclusions of 
any individual package-list, but if we specify them all together, 
like this, then we need to ensure that all are published as a unit.  
Alternatively, we could keep them together, like this, but initially 
cut the list back to a minimal subset, then incrementally grow it and 
republish, as we publish the individual components.

> Oddity: includes all of the msys-*.xml manifests, but 
> ALSO references the mingw32-autotool ones; I'm not sure if that's
> the right thing to do, but it's necessary because the
> mingw32-autotools are part of the msys-developer-toolkit meta
> package.

I tend to wonder if msys-dtk is not a misnomer; perhaps it would seem 
less confusing if this were renamed as mingw-dtk, with the new tools, 
which replace the old msys-dvlpr, becoming the new msys-dtk?

> msys-base.xml
> ========
> The core installation, approximately equivalent to the old
> monolithic MSYS installer. Virtual.

It's almost there, subject to deciding on the disposition of the 
package-list specs to resolve its dependencies (see above).  However, 
the package spec itself does need at least one "release" spec, to 
make it installable, (and that *may* need to be wrapped within a 
"component" container, to satisfy any dependency look-up).

Once you've added this, you've then effectively specified a version 
for the meta-package itself, so you also have the option of using '%' 
matching in the "requires" specs, if you deem it appropriate.

> msys-developer-toolkit.xml (alias msys-dtk)
> ========
> Approximately equivalent to the old msys-dtk-1.0.1 monolithic
> installer. Odd in that it includes some packages that are msys and
> install into /, and the mingw32-autotools that install into /mingw.

Again, this needs a "release" spec, to make it installable.

> Also, it needs to specify a dependency on the msys-base meta
> package, but I'm not sure how to do that:
>    <requires ge="msys-base-*-msys-*-bin.virtual" />
> doesn't seem right, because, well, there is no tarball with that
> signature.

If you add:

  <component class="bin">
    <release tarname="msys-base-1.0.14-1-msys-1.0.14-bin.virtual" />
  </component>

to the msys-base package spec (in msys-base.xml), you provide such a 
signature, relating it to a virtual tarball.  (I've used ".meta", 
rather than ".virtual", in my own trial manifests; I guess it would 
be good to agree a common standard here, but I've no particular 
preference for either one -- can we put it to a vote, please)?

> msys-system-builder.xml (alias msys-dvlpr)
> ========
> Functionally equivalent to the old msysDVLPR kit, but very
> different since it has the new msys-gcc/binutils, plus the
> msys-flavor autotools, and the msys-core -dev/-dbg packages.

Once again, it needs a "release" spec.

> It 
> does NOT include the -dev package for any of the msys libraries
> (libbz2, libarchive, libopenssl, etc). Those should be installed
> as-needed, individually IMO.

I don't disagree; as the actual developers, your judgement, and 
Cesar's, should trump mine anyway.

> Also needs to specify a dependency on 
> the msys-base meta package.

Same as in the DTK case.

-- 
Regards,
Keith.