Looking for testers: RPM 4.9 alpha

[Panu Matilainen]

On Tue, 30 Nov 2010, Erik van Pienbroek wrote:

> Panu Matilainen schreef op di 30-11-2010 om 22:10 [+0200]:
>> On Tue, 30 Nov 2010, Erik van Pienbroek wrote:
>>> If I understand your blog entry correctly then we (the Fedora MinGW SIG)
>>> are recommended to use something like this:
>>>
>>> %__mingw32_provides %{_mingw32_findprovides}
>>> %__mingw32_requires %{_mingw32_findrequires}
>>>
>>> Is this correct or do you recommend something different?
>>
>> That alone wont do anything at all, to create a new "file attribute"
>> called mingw32 you'd add a file like this to a suitable package,
>> mingw32-filesystem probably:
>>
>> /usr/lib/rpm/fileattrs/mingw32.attr:
>>
>> %__mingw32_requires	/usr/lib/rpm/mingw32-find-requires.sh
>> %__mingw32_provides	/usr/lib/rpm/mingw32-find-provides.sh
>> %__mingw32_magic	^PE32 executable for MS Windows.* 80386 32-bit$
>>
>> The magic rule is based on what 'file -b <file>' outputs for mingw32
>> executables and dll's - the above includes both, but you can make it
>> tighter to only include DLL's or have different extractors for DLL's and
>> EXE's by creating two rules instead of just one etc. Or if libmagic
>> strings aren't good ("fakedll" binaries from Wine would match the above
>> rule), path based regexes can be used too. It all depends on what makes
>> sense in a given scenario.
>>
>> You could also easily have a mingw32-specific pkg-config dependency
>> extractor which uses a different namespace than the regular pkgconfig(foo)
>> and only activates on .pc files from the mingw32 sys-root directory.
>>
>> And with necessary mingw32-specific .attr files in place through
>> buildrequires, there's no need for override kludges in each and every
>> mingw32 spec.
>
> Ah yes, thanks for the detailed information. This sure looks interesting
> for us! I'll try to play around a bit with this in a mock environment
> and see if it's possible to update our packaging guidelines to make use
> of it.

Do play around with it if you can, but I'd suggest leaving the packaging 
guideline considerations until the new rpm has actually landed AND gotten 
past the final feature acceptance line. The mechanism is likely to grow 
some enhancements before that, and also more than just mingw32 guidelines 
should be revisited + revised then (and might well be F16 material)

 	- Panu -