Menu

#2070 mingw-get requires element feature

INSTALLER
closed
None
Feature
rejected
Unknown
False
2019-03-06
2013-09-27
Earnie Boyd
No

I would like to see the requires element be able to resolve to a package name in addition to the release tarname.

Something like

<requires eq="mingw32-libgcc"/>

Should resolve to the latest release of the package.

Discussion

  • Keith Marshall

    Keith Marshall - 2019-03-06
    • status: assigned --> closed
    • Resolution: none --> rejected
     
  • Keith Marshall

    Keith Marshall - 2019-03-06

    I don't understand the motivation for this request. Firstly, IMO, a requirements specification needs to be explicit, at least to the component level, (which your example isn't). Secondly, AFAICT, the existing mechanism fully supports the capability you appear to be seeking:

    <requires eq="mingw32-libgcc-*-mingw32-dll-1.tar" />
    

    will match the currently installed version of the DLL component, with ABI version 1, (and, to me, ambiguity in an ABI version number makes no sense whatsoever); if there is no "currently installed" version, then it will select the latest available version.

    If the above "wildcard" form isn't sufficient, then there are alternative forms:

    <requires ge="mingw32-libgcc-4.8.2-mingw32-dll-1.tar" />
    

    will match any version from 4.8.2 onwards, while, (perhaps less usefully):

    <requires le="mingw32-libgcc-5.3.0-mingw32-dll-1.tar" />
    

    will match anything up to, and including version 5.3.0, but will reject any newer version. These two latter forms may even be combined, to specify a version range:

    <requires
        ge="mingw32-libgcc-4.8.2-mingw32-dll-1.tar"
        le="mingw32-libgcc-5.3.0-mingw32-dll-1.tar"
    />
    

    will match version 4.8.2 or later, but no later than version 5.3.0, and if this still isn't sufficient, you may also choose the non-inclusive gt and lt attributes, instead of the inclusive ge and le forms.

    Note that there is also a "%" wildcard alternative to "*"; this is useful for intra-package component dependencies, where component "foo" of package "fubar" requires component "bar" of the same package, with identically the same package version number. This isn't really useful for inter-package dependencies.

    I'm closing this, because I can see no reason to pursue it further. If you believe that it merits further consideration, please open a new ticket on OSDN, and provide a more reasoned motivation for your request.