From: Cesar S. <ces...@gm...> - 2010-04-25 13:47:57
Attachments:
gcc-index.xml
|
Hi, I am working on the mingw-get package index for gcc 4.5.0 and its dependencies. While writing down the entries for gmp and mpfr, I came across the issue of how to specify a dependency on a specific DLL soname, since it doesn't necessarily have anything to do with the package version. For instance: * libmpfr-1.dll expects libgmp-10.dll to be installed. * libgmp-10.dll currently comes from the libgmp-5.0.1-1-mingw32-dll-10.tar.lzma package, but any libgmp-*-mingw32-dll-10.tar.lzma will do. * On the other hand, a hypothetical future libgmp-5.3.1-1-mingw32-dll-15.tar.lzma won't do, since it will install libgmp-15.dll, not libgmp-10.dll. An approach that seems to work right now is to use "dll-soname" as the component class. Example: <package name="libgmp"> <component class="dll-10"> this ==> ^^^^^^ <release tarname="libgmp-5.0.1-1-mingw32-dll-10.tar.lzma" /> </component> </package> <package name="libmpfr"> <component class="dll-1"> <release tarname="libmpfr-2.4.1-1-mingw32-dll-1.tar.lzma"> <requires ge="libgmp-*-mingw32-dll-10.tar"/> matches ==> ^^^^^^ </release> </component> </package> In addition, in order to get all DLLs when typing "mingw-get install gmp" , I created a pseudo dll class in the gmp package. For example: <package name="gmp"> <component class="dev"> <release tarname="gmp-5.0.1-1-mingw32-dev.tar.lzma" /> </component> <component class="dll"> <release tarname="gmp-5.0.1-1-mingw32-dll.meta"> <requires eq="libgmp-5.0.1-1-mingw32-dll-10.tar.lzma" /> <requires eq="libgmpxx-5.0.1-1-mingw32-dll-4.tar.lzma" /> </release> </component> </package> Do you think this approach is reasonable? For your convenience, I attach my work in progress (gmp and mpfr only at the moment). Regards, Cesar |
From: Keith M. <kei...@us...> - 2010-04-26 19:44:41
|
On Sunday 25 April 2010 14:47:44 Cesar Strauss wrote: > While writing down the entries for gmp and mpfr, I came across the > issue of how to specify a dependency on a specific DLL soname, > since it doesn't necessarily have anything to do with the package > version. > > For instance: > > * libmpfr-1.dll expects libgmp-10.dll to be installed. > > * libgmp-10.dll currently comes from the > libgmp-5.0.1-1-mingw32-dll-10.tar.lzma package, but any > libgmp-*-mingw32-dll-10.tar.lzma will do. > > ... > > An approach that seems to work right now is to use "dll-soname" as > the component class. Example: > > <package name="libgmp"> > <component class="dll-10"> > . > . > . > <package name="libmpfr"> > <component class="dll-1"> > <release tarname="libmpfr-2.4.1-1-mingw32-dll-1.tar.lzma"> > <requires ge="libgmp-*-mingw32-dll-10.tar"/> Not how I'd like it to work, but I guess you discovered that <release tarname="libmpfr-2.4.1-1-mingw32-dll-1.tar.lzma"> <requires eq="libgmp-*-mingw32-dll-10.tar" /> leads to a less than helpful error message, suggesting that you've got the specs wrong. You haven't -- more bug hunting for me :( > In addition, in order to get all DLLs when typing "mingw-get > install gmp" , I created a pseudo dll class in the gmp package. > For example: > > <package name="gmp"> > <component class="dev"> > <release tarname="gmp-5.0.1-1-mingw32-dev.tar.lzma" /> > </component> > <component class="dll"> > <release tarname="gmp-5.0.1-1-mingw32-dll.meta"> > <requires eq="libgmp-5.0.1-1-mingw32-dll-10.tar.lzma" /> > <requires eq="libgmpxx-5.0.1-1-mingw32-dll-4.tar.lzma" /> > </release> > </component> > </package> > > Do you think this approach is reasonable? If it works, as it seems to, then yes, I'd say it is reasonable, but the hoops you've had to jump through, to get the proper DLL version match, seem to make it rather awkward and kludgy. Hopefully, we can improve on that, with improved requirements matching, but what you've got so far looks good for interim use. One minor point: your <release tarname="gmp-5.0.1-1-mingw32-dll.meta"> isn't sufficient to make that release virtual. Neither can you add a `class="virtual"' attribute on the <release> element itself, (as you can for a <package> element -- maybe it should also be allowed for a <release>? And also for a <component>? But in this latter case it would conflict with the existing use of the class attribute; perhaps use a `type="dll"' attribute, instead of the existing usage of the class attribute in this context?) For the time being, you need to add an explicit <download> override: <release tarname="gmp-5.0.1-1-mingw32-dll.meta"> <download tarname="none" /> <requires eq="libgmp-5.0.1-1-mingw32-dll-10.tar.lzma" /> <requires eq="libgmpxx-5.0.1-1-mingw32-dll-4.tar.lzma" /> </release> And finally: in my discussion last week, with Chuck, I suggested that perhaps the package names, (i.e. the name attribute on the <package> elements), should be prefixed with the subsystem name, at least in the case of MSYS packages, to avoid ambiguity. Perhaps we should consider a similar policy for mingw32 packages; or do we want to adopt the policy that mingw32 is the default, and thus it is implied if not so prefixed? (It is redundant anyway, in *both* cases, as any possible ambiguity should be resolved by the subsystem attribute of the containing <package-collection>; I'm thinking of what will be displayed by the GUI version of the installer, but it may be better to just address the issue in that context, and avoid cluttering the package specs with redundant information). -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2010-04-29 17:16:11
|
On Monday 26 April 2010 16:44:19 Keith Marshall wrote: > Not how I'd like it to work, but I guess you discovered that > > <release tarname="libmpfr-2.4.1-1-mingw32-dll-1.tar.lzma"> > <requires eq="libgmp-*-mingw32-dll-10.tar" /> > > leads to a less than helpful error message, suggesting that you've > got the specs wrong. You haven't -- more bug hunting for me :( I believe I've identified the problem here, and have committed a fix; this *should* now work correctly. > > * libmpfr-1.dll expects libgmp-10.dll to be installed. > > > > * libgmp-10.dll currently comes from the > > libgmp-5.0.1-1-mingw32-dll-10.tar.lzma package, but any > > libgmp-*-mingw32-dll-10.tar.lzma will do. This requirement *should* now be correctly resolved, when specified in a <requires> element of the form: <requires eq="libgmp-*-mingw32-dll-10.tar" /> > > * On the other hand, a hypothetical future > > libgmp-5.3.1-1-mingw32-dll-15.tar.lzma won't do, since it will > > install libgmp-15.dll, not libgmp-10.dll. According to the source code, (pkgActionItem::SelectIfMostRecentFit in src/pkgexec.cpp), the DLLVERSION element of the soname is *always* explicitly matched for *equality*; even when specified as: <requires ge="libgmp-*-mingw32-dll-10.tar" /> (the inequality match is applied only to the package and subsystem version specs, and not to the component version). Thus, in the case of your hypothetical libgmp-5.3.1-1-mingw32-dll-15.tar, it would not be considered as a viable match for the <requires> spec anyway. I think this is probably desirable behaviour. > > An approach that seems to work right now is to use "dll-soname" > > as the component class. Example: > > > > <package name="libgmp"> > > <component class="dll-10"> It *should* work just as well, to write this as: <package name="libgmp"> <component class="dll"> . . and leave the dependency resolver to identify the appropriate soname version from the embedded <release> elements; indeed, from my current debug build of mingw-get, with: <package name="libgmp"> <affiliate group="MinGW Libraries (DLL)" /> <description lang="en" title="DLL for the gmp library"/> <component class="dll"> <release tarname="libgmp-5.0.1-1-mingw32-dll-10.tar.lzma" /> <release tarname="libgmp-5.2.1-1-mingw32-dll-10.tar.lzma" /> <release tarname="libgmp-5.3.1-1-mingw32-dll-15.tar.lzma" /> </component> </package> <package name="libmpfr"> <affiliate group="MinGW Libraries (DLL)" /> <description lang="en" title="DLL for the mpfr library"/> <component class="dll"> <release tarname="libmpfr-2.4.1-1-mingw32-dll-1.tar.lzma"> <requires eq="libgmp-*-mingw32-dll-10.tar"/> </release> </component> </package> <package name="libmpfr-future"> <affiliate group="MinGW Libraries (DLL)" /> <description lang="en" title="DLL for the mpfr library"/> <component class="dll"> <release tarname="libmpfr-3.0.1-1-mingw32-dll-1.tar.lzma"> <requires eq="libgmp-*-mingw32-dll-15.tar"/> </release> </component> </package> I see: $ ./mingw-get.exe install libmpfr-dll . . install: libgmp-5.2.1-1-mingw32-dll-10.tar.lzma install: libmpfr-2.4.1-1-mingw32-dll-1.tar.lzma $ ./mingw-get.exe install libmpfr-future-dll . . install: libgmp-5.3.1-1-mingw32-dll-15.tar.lzma install: libmpfr-3.0.1-1-mingw32-dll-1.tar.lzma -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2010-04-26 21:50:50
|
On Monday 26 April 2010 16:44:19 Keith Marshall wrote: > And finally: in my discussion last week, with Chuck, I suggested > that perhaps the package names, (i.e. the name attribute on the > <package> elements), should be prefixed with the subsystem name, > at least in the case of MSYS packages, to avoid ambiguity. > Perhaps we should consider a similar policy for mingw32 packages; > or do we want to adopt the policy that mingw32 is the default, and > thus it is implied if not so prefixed? (It is redundant anyway, > in *both* cases, as any possible ambiguity should be resolved by > the subsystem attribute of the containing <package-collection>; > I'm thinking of what will be displayed by the GUI version of the > installer, but it may be better to just address the issue in that > context, and avoid cluttering the package specs with redundant > information). Sorry. Belay that parenthesised closing comment; a prefix *isn't* entirely redundant. How else would a CLI user disambiguate $ mingw-get install binutils say, to indicate whether it is the mingw32 or the MSYS variant he wishes to install? -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-04-26 22:41:00
|
On Mon, 26 Apr 2010 21:50 +0000, "Keith Marshall" wrote: > On Monday 26 April 2010 16:44:19 Keith Marshall wrote: > > And finally: in my discussion last week, with Chuck, I suggested > > that perhaps the package names, (i.e. the name attribute on the > > <package> elements), should be prefixed with the subsystem name, > > at least in the case of MSYS packages, to avoid ambiguity. > > Perhaps we should consider a similar policy for mingw32 packages; > > or do we want to adopt the policy that mingw32 is the default, and > > thus it is implied if not so prefixed? As you point out below, it *isn't* redundant -- unless we want to redefine "package name" when used in the context of "an argument to mingw-get or a 'requires' specification" to be <SUBSYS>-<PKGNAME>, where <SUBSYS> and <PKGNAME> are used to match fields in their *canonical* locations in the actual release and/or tarball names. But (given what I recall from your Friday post) that would seriously muck up the fragment search rules and pattern matching as already implemented. So...in *practice*, it is not redundant in any context, unless we adopt a formalism to implicitly assume something (e.g. "mingw") when the prefix is not present. Hmmm...I think I like "assume mingw, unless prefixed with msys" -- even though this means certain oddities like "there is no 'bash' package, there is only 'msys-bash'" -- but there are distinct 'xz' and 'msys-xz' packages. mingw-get mingw-mingw-runtime mingw-get mingw-w32api mingw-get mingw-gcc mingw-get mingw-g++ mingw-get mingw-binutils mingw-get mingw-automake1.11 mingw-get mingw-automake1.10 mingw-get mingw-automake ## (wrapper) mingw-get mingw-autoconf2.5 mingw-get mingw-autoconf ## (wrapper) mingw-get msys-w32api mingw-get msys-binutils mingw-get msys-gcc mingw-get msys-autoconf ## there is only one mingw-get msys-automake ## there is only one vs. mingw-get mingw-runtime mingw-get w32api mingw-get gcc mingw-get g++ mingw-get binutils mingw-get automake1.11 mingw-get automake1.10 mingw-get automake ## (wrapper) mingw-get autoconf2.5 mingw-get autoconf ## (wrapper) mingw-get msys-w32api mingw-get msys-binutils mingw-get msys-gcc mingw-get msys-autoconf ## there is only one mingw-get msys-automake ## there is only one I think the latter set makes more sense. (I think I am right in assuming that this is purely a *policy* issue affecting how we name our packages and *.xml scripts -- and has no implication in the actual code of mingw-get itself? I wouldn't want to embed this sort of logic into mingw-get source...) > (It is redundant anyway, > > in *both* cases, as any possible ambiguity should be resolved by > > the subsystem attribute of the containing <package-collection>; > > I'm thinking of what will be displayed by the GUI version of the > > installer, but it may be better to just address the issue in that > > context, and avoid cluttering the package specs with redundant > > information). > > Sorry. Belay that parenthesised closing comment; a prefix *isn't* > entirely redundant. How else would a CLI user disambiguate > > $ mingw-get install binutils > > say, to indicate whether it is the mingw32 or the MSYS variant he > wishes to install? Most users will always want the "mingw" version of ANY package, rather than the (possibly confusing, and useful only to *msys-dvlprs*) msys version when there are two "identically-named" packages. So, I think "no subsys prefix" == mingw; msys requires a prefix. And, I *bet* that MOST users when they choose to install ANY "msys" package, will simply say "gimme all that basic msys goodness" via some meta/virtual package, and that'll be the last they think about it. But I'd be happy with either prefixing policy. FWIW, I'm still mulling Keith's long Friday post, and will respond after I digest it some more. -- Chuck |
From: Keith M. <kei...@us...> - 2010-05-12 18:17:26
|
On Monday 26 April 2010 23:40:54 Charles Wilson wrote: > Hmmm...I think I like "assume mingw, unless prefixed with msys" -- > even though this means certain oddities like "there is no 'bash' > package, there is only 'msys-bash'" -- but there are distinct 'xz' > and 'msys-xz' packages. Yes, but "mingw" is ambiguous; does it imply "mingw32" or "mingw64"? The two would require separate package sets, and, since our primary product line is still "mingw32", I guess that we would need to agree that unprefixed package names implicitly refer to "mingw32". > ... examples snipped ... > > I think the latter set makes more sense. (I think I am right in > assuming that this is purely a *policy* issue affecting how we > name our packages and *.xml scripts Yes. > -- and has no implication in > the actual code of mingw-get itself? I wouldn't want to embed > this sort of logic into mingw-get source...) I wouldn't either, but I can't see any reason why it would need to be so. > > Sorry. Belay that parenthesised closing comment; a prefix > > *isn't* entirely redundant. How else would a CLI user > > disambiguate > > > > $ mingw-get install binutils > > > > say, to indicate whether it is the mingw32 or the MSYS variant > > he wishes to install? > > Most users will always want the "mingw" version of ANY package, > rather than the (possibly confusing, and useful only to > *msys-dvlprs*) msys version when there are two "identically-named" > packages. So, I think "no subsys prefix" == mingw; msys requires > a prefix. Makes sense, subject to "no prefix" == mingw32 > And, I *bet* that MOST users when they choose to > install ANY "msys" package, will simply say "gimme all that basic > msys goodness" via some meta/virtual package, and that'll be the > last they think about it. I'm sure you're right. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-05-13 04:29:08
|
On 5/12/2010 9:54 AM, Keith Marshall wrote: > On Monday 26 April 2010 23:40:54 Charles Wilson wrote: >> Hmmm...I think I like "assume mingw, unless prefixed with msys" -- >> even though this means certain oddities like "there is no 'bash' >> package, there is only 'msys-bash'" -- but there are distinct 'xz' >> and 'msys-xz' packages. > Makes sense, subject to "no prefix" == mingw32 OK. So, fer instance, we already have: msys/msys-libtool.xml mingw32/libtool.xml -- Chuck |
From: Earnie <ea...@us...> - 2010-05-13 12:11:51
|
Charles Wilson wrote: > On 5/12/2010 9:54 AM, Keith Marshall wrote: > > On Monday 26 April 2010 23:40:54 Charles Wilson wrote: > >> Hmmm...I think I like "assume mingw, unless prefixed with msys" > >> -- even though this means certain oddities like "there is no > >> 'bash' package, there is only 'msys-bash'" -- but there are > >> distinct 'xz' and 'msys-xz' packages. > > > Makes sense, subject to "no prefix" == mingw32 > > OK. So, fer instance, we already have: > > msys/msys-libtool.xml > mingw32/libtool.xml > That just doesn't look right and I hadn't made up my mind till I saw this. IMO, it would be better if we from the start require the prefix so that we have: msys/msys-libtool.xml mingw32/mingw32-libtool.xml And for the most likely near future: mingw64/mingw64-libtool.xml The prefix will make it less confusing and have better pragmatics for future enhancements. |
From: Charles W. <cwi...@us...> - 2010-05-13 12:38:23
|
On 5/13/2010 8:11 AM, Earnie wrote: > That just doesn't look right and I hadn't made up my mind till I saw > this. IMO, it would be better if we from the start require the prefix > so that we have: > > msys/msys-libtool.xml > mingw32/mingw32-libtool.xml > > And for the most likely near future: > > mingw64/mingw64-libtool.xml > > The prefix will make it less confusing and have better pragmatics for > future enhancements. You realize that the name of the xml file must also match the package name, which is what will probably appear in the GUI chooser, and is what you must tell mingw-get to install? So mingw-get mingw32-gcc mingw32-g++ mingw32-gfortran mingw32-binutils will work, but the following will fail: mingw-get gcc g++ gfortran binutils under your scenario. Is that what you really want? Exactly how much accommodation should we make ("pragmatics and future enhancements") for a project that (a) deliberately forked away, (b) is run by a different team, and (c) doesn't follow the same rules ("public sources only") for what gets included in their version of the microsoftish header files? Unless there are plans for us to start producing our own version of a 64 bit compiler, without using the mingw64 project's work...talk about potential for confusion! -- Chuck |
From: Earnie <ea...@us...> - 2010-05-13 13:40:53
|
Charles Wilson wrote: > On 5/13/2010 8:11 AM, Earnie wrote: >> That just doesn't look right and I hadn't made up my mind till I saw >> this. IMO, it would be better if we from the start require the prefix >> so that we have: >> >> msys/msys-libtool.xml >> mingw32/mingw32-libtool.xml >> >> And for the most likely near future: >> >> mingw64/mingw64-libtool.xml >> >> The prefix will make it less confusing and have better pragmatics for >> future enhancements. > > You realize that the name of the xml file must also match the package > name, which is what will probably appear in the GUI chooser, and is what > you must tell mingw-get to install? > > So > > mingw-get mingw32-gcc mingw32-g++ mingw32-gfortran mingw32-binutils > > will work, but the following will fail: > > mingw-get gcc g++ gfortran binutils > > under your scenario. Is that what you really want? mingw-get --prefix=mingw32 gcc g++ gfortran binutils mingw-get --prefix=msys gcc g++ gfortran binutils mingw-get gcc g++ gfortran binutils The later would default --prefix to mingw32 but the package xml files will be named properly. The --prefix default could also be controlled by an environment variable. --prefix could be named something else, just what I was thinking in the moment. > > Exactly how much accommodation should we make ("pragmatics and future > enhancements") for a project that (a) deliberately forked away, (b) is > run by a different team, and (c) doesn't follow the same rules ("public > sources only") for what gets included in their version of the > microsoftish header files? > > Unless there are plans for us to start producing our own version of a 64 > bit compiler, without using the mingw64 project's work...talk about > potential for confusion! > I was talking about MinGW proper. The history of MinGW provided for a future delivery of 64 bit binaries when it was named. We might as well plan in that direction. Earnie |
From: Keith M. <kei...@us...> - 2010-05-14 16:37:35
|
On Thursday 13 May 2010 14:34:20 Earnie wrote: > mingw-get --prefix=mingw32 [install] gcc g++ gfortran binutils > mingw-get --prefix=msys [install] gcc g++ gfortran binutils > mingw-get [install] gcc g++ gfortran binutils > > The later would default --prefix to mingw32 but the package xml > files will be named properly. Not that it matters, really. There is no formal requirement for the XML file name to match the package name -- see my earlier reply to Chuck. Indeed, there are cases where I would advocate package names which *don't* match their containing XML file names: e.g., *both* msys-findutils and msys-locate are derived from the upstream findutils sources; thus I would define both <package name="msys-findutils"> and <package name="msys-locate"> within a single msys-findutils.xml catalogue file. > The --prefix default could also be controlled by an environment > variable. It could, but I'd prefer it not to be. I'd rather let it be controlled by a setting in the user's local mingw-get configuration file, $MINGWROOT/var/lib/mingw-get/data/profile.xml, where I can give it a sane initial value in the distributed template. > --prefix could be named something else, just what I was thinking > in the moment. It would probably fit in with my ideas for a future -subsystem option; (note that I use getopt_long_only() to parse command line options, so -subsystem and --subsystem are equivalent). -- Regards, Keith. |
From: Keith M. <kei...@us...> - 2010-05-13 19:53:19
|
On Thursday 13 May 2010 13:28:37 Charles Wilson wrote: > You realize that the name of the xml file must also match the > package name, That isn't strictly true; there is no formal requirement for the two to be the same, (or even similar), although for the sake of our sanity as package maintainers, preserving some logical relationship would be prudent. > which is what will probably appear in the GUI > chooser, and is what you must tell mingw-get to install? That would be the name attribute of the <package> declaration, with the class attribute of the <component> appended. > So > > mingw-get mingw32-gcc mingw32-g++ mingw32-gfortran \ > mingw32-binutils > > will work, but the following will fail: It will, if you add the magic word... mingw-get install ... > mingw-get gcc g++ gfortran binutils But this could also work, even when the prefix is in place in the package name, if appropriate alias attributes are specified, but I don't really want to promote that; (I added the alias feature to accommodate mingwrt and mingw-runtime as variant names for releases of the same package, but a meta-package solution is probably to be preferred, now that it works). BTW, in my current setup, the fully qualified package name for gcc is gcc-core, with gcc as an alias, and both gcc-core and binutils are redundantly specified in the above, because both will be <requires> dependencies of each of the other two. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-05-14 06:12:38
|
On 5/13/2010 3:53 PM, Keith Marshall wrote: >> mingw-get gcc g++ gfortran binutils > > But this could also work, even when the prefix is in place in the > package name, if appropriate alias attributes are specified, but I > don't really want to promote that; (I added the alias feature to > accommodate mingwrt and mingw-runtime as variant names for releases > of the same package, But it seems like a perfect solution: If we have mingw32-libtool.xml: <package name="mingw32-libtool"> ... </package> <package name="mingw32-libltdl"> ... </package> then we just add <package name="mingw32-libtool"> <alias name="libtool> ... </package> <package name="mingw32-libltdl"> <alias name="libltdl> ... </package> and there you go: the official package name, and the associated xml file name, has the desired prefix, but without the prefix it will acts just as we discussed last week. > but a meta-package solution is probably to be > preferred, now that it works). You mean an entire new .xml file, with full <description> tags and everything ('cause I don't think mingw-get-gui should recursively attempt to show the descriptions of <require>'ed elements) have to be maintained and kept in sync, just so that we can have an... alias ...for a package? The files will ALWAYS be out of sync, and it would be a pain to maintain. Plus, it's twice as much parsing (which, for a distribution the size of MSYS may not be a big deal, but for cygwin's 1.2MB setup.ini it IS). If we want two different package names to refer to the same set of tarballs, I really think your <alias> approach is the way to go. -- Chuck |
From: Keith M. <kei...@us...> - 2010-05-14 16:37:22
|
On Friday 14 May 2010 07:12:08 Charles Wilson wrote: > On 5/13/2010 3:53 PM, Keith Marshall wrote: > >> mingw-get [install] gcc g++ gfortran binutils > > > > But this could also work, even when the prefix is in place in > > the package name, if appropriate alias attributes are specified, > > but I don't really want to promote that; (I added the alias > > feature to accommodate mingwrt and mingw-runtime as variant > > names for releases of the same package, > > But it seems like a perfect solution: If we have > mingw32-libtool.xml: > > <package name="mingw32-libtool"> > ... > </package> > <package name="mingw32-libltdl"> > ... > </package> > > then we just add > > <package name="mingw32-libtool"> > <alias name="libtool> Conceptually, yes, but let's formalise the syntactical technical details; as currently implemented, mingw-get expects: <package name="package-name" alias="namelist ..."> where "namelist ..." is a white-space separated list of acceptable alias names, so in this example it would be: <package name="mingw32-libtool" alias="libtool"> > ... > </package> > <package name="mingw32-libltdl"> > <alias name="libltdl> > ... > </package> > > and there you go: the official package name, and the associated > xml file name, has the desired prefix, but without the prefix it > will acts just as we discussed last week. > > > but a meta-package solution is probably to be > > preferred, now that it works). > > You mean an entire new .xml file, with full <description> tags and > everything No, I mean one xml file, with the full package description for the primary package name, with a version agnostic meta-package declared in the same file, with the alternative name, and with appropriate <release> and <requires> specs referring back to the primary. > ('cause I don't think mingw-get-gui should recursively > attempt to show the descriptions of <require>'ed elements) No, I don't think it should either. > have to > be maintained and kept in sync, just so that we can have an... > > alias > > ...for a package? The files will ALWAYS be out of sync, and it > would be a pain to maintain. Plus, it's twice as much parsing > (which, for a distribution the size of MSYS may not be a big deal, > but for cygwin's 1.2MB setup.ini it IS). If we want two different > package names to refer to the same set of tarballs, I really think > your <alias> approach is the way to go. My concern with the alias mechanism is that it makes it very easy to introduce ambiguity -- two distinct primary package names, but with a common alias would not be acceptable -- but on reflection, using a meta-package would just be a clumsier way to achieve a similarly undesirable outcome, so alias does seem to be a better solution. In any case, I've no plans to remove the feature; however, I do need to fix its implementation, because at present, with[*] <package name="mingwrt" alias="mingw-runtime"> : : I can do $ mingw-get install mingwrt-dll but I can't do $ mingw-get install mingw-runtime-dll This disparity does seem to be exclusive to matching component qualified alias names specified on the command line, since my gcc package spec has[*] <package name="gcc-core" alias="gcc"> : : <requires ge="mingw-runtime-*-mingw32-dll.tar" /> : and $ mingw-get install gcc works fine, and *does* pull in the mingwrt-dll dependency; yet another bug to track down :( [*] Obviously, in line with our recent discussions, these could be rewritten as (say) <package name="mingw32-mingwrt" alias="mingwrt mingw-runtime"> and <package name="mingw32-gcc-core" alias="gcc gcc-core"> -- Regards, Keith. |