MinGW provides and requires automatic generation with RPM 4.9

[Panu Matilainen]

On 05/19/2011 08:25 PM, Kalev Lember wrote:
> On 05/19/2011 02:19 PM, Panu Matilainen wrote:
>> On 05/19/2011 01:49 PM, Kalev Lember wrote:
>>> This is the contents of the mingw32.attr file:
>>> %__mingw32_provides     %{_rpmconfigdir}/mingw32-find-provides.sh
>>> %__mingw32_requires     %{_rpmconfigdir}/mingw32-find-requires.sh
>>> %__mingw32_magic        ^PE32 executable.* Intel 80386.*, for MS Windows$
>>> %__mingw32_path         ^%{_mingw32_prefix}/.*$
>>
>> Note that this doesn't work quite as you want it to, just yet: in rpm
>> 4.9.0 path and magic are handled as an inclusive or, whereas this (and
>> various other things) needs an and-rule. Adding support for this is
>> technically trivial, just the naming is under consideration:
>> http://lists.rpm.org/pipermail/rpm-maint/2011-May/003022.html
>
> Ah, good catch. I would love to see the "and-rule" in RPM, it would
> certainly make things easier.
>
>
>>> I am planning to add the new mingw32.attr file to the mingw32-filesystem
>>> package in rawhide soon. Any objections?
>>
>> Depends on how soon your "soon" is :) - you'll probably want to wait
>> until the and-rule support lands in rawhide rpm. OTOH if you're in
>> hurry, I guess you could get away with just defining mingw32_magic and
>> leaving the path out for now, Wine is probably the only thing besides
>> mingw32 having Windows PE32 executables (and you could have an
>> exclude-rule for the wine-paths just to be on the safe side).
>
> Mono assemblies also have a very similar magic, which is somewhat hard
> to discern from the usual PE32 magic.
>
> mingw32 cross compiled zlib1.dll:
> PE32 executable (DLL) (console) Intel 80386 (stripped to external PDB),
> for MS Windows
> Mono assembly nunit.core.dll:
> PE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS
> Windows

Ah, mono too. Those could be filtered out with an exclude_magic rule on 
Mono/.Net but...

>
> If we currently don't have the "and-rule", I would go for a simple path
> based regex that matches all the .dll and .exe files in the mingw32
> sysroot and forget about the libmagic matches for now. Once the
> "and-rule" makes it in rawhide, we can switch over to using that.
>
> The advantages with plain path based regexes are:
>   - It's similar to how we are matching the files right now, so it would
>     be harder to regress something;
>   - It would work with RPM 4.9.0 and we would be able to backport the
>     mingw32-filesystem changes to F15 to provide compatibility for
>     maintainers who want to keep F15 and rawhide spec files in sync;
>   - We wouldn't have to worry about excluding strange paths where some
>     .dll files might be, like /usr/share/.

Indeed, for something like mingw32 where everything lives in a distinct 
directory structure with easily recognizable suffixes, additional 
magic-rules adds little value over plain path-based regexes.

>
>> Depends on how soon your "soon" is :)
>
> I would actually like to get the fileattr dependency extraction in
> rather sooner than later. There's no guarantee I would have time to work
> on it in a month or two and I'd rather finish it now when I have the time.

Ok. Well, if only path based regexes are used then that will work right 
now in both rawhide and F15.

	- Panu -