It's that time of year again, although there seems to be an off-by-one bug in the calendar system causing some inconsistency in the timing wrt last year :P http://lists.fedoraproject.org/pipermail/devel/2009-November/042339.html
Anyway, before going to beta and starting the inevitable Fedora Feature process, we'd like some extra preliminary testing to catch out any major issues early on.
The alpha isn't supposed to eat your system alive or anything, but proceed with appropriate cauting, backing up the rpmdb etc, as usual.
The draft release notes are at http://rpm.org/wiki/Releases/4.9.0 and Fedora compatible SRPM(s) can be found at http://laiskiainen.org/rpm/srpms/
In particular, I'm interested in feedback on the new, pluggable and enhanced dependency extration system. Documentation is scarce at the moment but some background and examples can be found here: http://laiskiainen.org/blog/?p=35
Note that the current SRPM is missing gstreamer plugin, cups driver and automatic "devel-symlink" dependency generation, on purpose: the highly application-domain specific gstreamer + cups bits can now be fully moved out of rpm to gstreamer-devel etc, eliminating the need for embedding python inside /bin/sh scripts and such to avoid extra dependencies. The devel-symlink generation will stay in rpm but will probably change somewhat, it can be handled in a more generic fashion now.
Please report any oddities found, preferably to rpm.org Trac at http://rpm.org/newticket or rpm-maint list (or here for fedora-specific discussions/suggestions etc).
P.S. Pjones, before you ask ;) The much wanted ordering-only feature is not in the alpha, but is likely to make it into beta. The patch itself is fairly trivial and non-intrusive, we're just trying to figure sane spec syntax for it (discussion ongoing on rpm-maint)
- Panu -
2010/11/26 Panu Matilainen pmatilai@laiskiainen.org:
the new, pluggable and enhanced dependency extration system.
That's really awesome!
On 11/26/2010 04:50 PM, Panu Matilainen wrote:
The draft release notes are at http://rpm.org/wiki/Releases/4.9.0 and Fedora compatible SRPM(s) can be found at http://laiskiainen.org/rpm/srpms/
I am using this now on my Fedora 14 box and I haven't noticed any obvious breakages. Beyond that, if you want me to test something, let me know.
Rahul
On Sat, 27 Nov 2010, Rahul Sundaram wrote:
On 11/26/2010 04:50 PM, Panu Matilainen wrote:
The draft release notes are at http://rpm.org/wiki/Releases/4.9.0 and Fedora compatible SRPM(s) can be found at http://laiskiainen.org/rpm/srpms/
I am using this now on my Fedora 14 box and I haven't noticed any obvious breakages.
Good.
Beyond that, if you want me to test something, let me know.
The new dependency generator is where I suspect some regressions might be lurking - try building packages (for example ones that you maintain), check that all the expected automatic dependencies are there and that it doesn't fall over in other ways.
- Panu -
On 11/28/2010 04:17 PM, Panu Matilainen wrote:
The new dependency generator is where I suspect some regressions might be lurking - try building packages (for example ones that you maintain), check that all the expected automatic dependencies are there and that it doesn't fall over in other ways.
aria2 local build failed locally but is successful if build on Koji. I am pretty sure it is the new RPM that is causing it to fail and I screwed up trying to downgrade the package and had to use rpm2cpio to put everything together again. If you want to test the build, grab the srpm from
http://koji.fedoraproject.org/koji/buildinfo?buildID=206683
Rahul
On Sun, 28 Nov 2010, Rahul Sundaram wrote:
On 11/28/2010 04:17 PM, Panu Matilainen wrote:
The new dependency generator is where I suspect some regressions might be lurking - try building packages (for example ones that you maintain), check that all the expected automatic dependencies are there and that it doesn't fall over in other ways.
aria2 local build failed locally but is successful if build on Koji. I am pretty sure it is the new RPM that is causing it to fail and I screwed up trying to downgrade the package and had to use rpm2cpio to put everything together again. If you want to test the build, grab the srpm from
Built fine here, dunno. What exactly went wrong with your build? "It failed" isn't a particularly helpful description.
- Panu -
Panu Matilainen wrote:
The draft release notes are at http://rpm.org/wiki/Releases/4.9.0
1. This change: | Packages with no files can now omit the %files section and still have | packages generated. is going to make it a PITA to conditionalize the building of subpackages, and it's going to break several existing KDE specfiles very badly (and with no warning!): RPM will silently generate empty subpackages where none is wanted.
More precisely, when we wanted to conditionalize or comment out the creation of a subpackage (e.g. in kde-l10n for languages which are currently not available), what we did so far was to %if out only the %files section for the subpackage, not %package or things like %post, and this would reliably omit the subpackage. Now we'll have to %if out ALL sections referring to the subpackage: %package to prevent the subpackage from being built, and all other sections referring to it because they'll error out if the %package is not there.
2. I presume this: | Unknown dependency qualifiers are now always treated as errors and abort | build also includes Requires(hint), or is that finally used now? The specfiles maintained or comaintained by Rex Dieter (and they're many!) have Requires(hint) in many places. If this is really an error now, then that change is breaking all of KDE and its dependencies and several other packages in Fedora.
Kevin Kofler
On Sun, 28 Nov 2010, Kevin Kofler wrote:
Panu Matilainen wrote:
The draft release notes are at http://rpm.org/wiki/Releases/4.9.0
- This change:
| Packages with no files can now omit the %files section and still have | packages generated. is going to make it a PITA to conditionalize the building of subpackages, and it's going to break several existing KDE specfiles very badly (and with no warning!): RPM will silently generate empty subpackages where none is wanted.
More precisely, when we wanted to conditionalize or comment out the creation of a subpackage (e.g. in kde-l10n for languages which are currently not available), what we did so far was to %if out only the %files section for the subpackage, not %package or things like %post, and this would reliably omit the subpackage. Now we'll have to %if out ALL sections referring to the subpackage: %package to prevent the subpackage from being built, and all other sections referring to it because they'll error out if the %package is not there.
This change can be reconsidered.
- I presume this:
| Unknown dependency qualifiers are now always treated as errors and abort | build also includes Requires(hint), or is that finally used now? The specfiles maintained or comaintained by Rex Dieter (and they're many!) have Requires(hint) in many places. If this is really an error now, then that change is breaking all of KDE and its dependencies and several other packages in Fedora.
...but this I've no sympathy for. You're relying on a stupid, longstanding bug on rpm that makes it accept Requires(randomjunk) in some situations: in older versions Requires(pre,junk) and Requires(junk) falls through silently in older versions but eg Requires(junk,pre) - and Requires(hint,pre) does give an error.
- Panu -
On Sun, 28 Nov 2010 12:15:52 +0200 (EET) Panu Matilainen pmatilai@laiskiainen.org wrote:
On Sun, 28 Nov 2010, Kevin Kofler wrote:
Panu Matilainen wrote:
The draft release notes are at http://rpm.org/wiki/Releases/4.9.0
- This change:
| Packages with no files can now omit the %files section and still have | packages generated. is going to make it a PITA to conditionalize the building of subpackages, and it's going to break several existing KDE specfiles very badly (and with no warning!): RPM will silently generate empty subpackages where none is wanted.
More precisely, when we wanted to conditionalize or comment out the creation of a subpackage (e.g. in kde-l10n for languages which are currently not available), what we did so far was to %if out only the %files section for the subpackage, not %package or things like %post, and this would reliably omit the subpackage. Now we'll have to %if out ALL sections referring to the subpackage: %package to prevent the subpackage from being built, and all other sections referring to it because they'll error out if the %package is not there.
This change can be reconsidered.
Wouldn't it be better instead to create a specific directive to disable unwanted subpackages ?
Something like: %suppress <subpackagename>
This would make it clear what the author of the RPMs wants to do w/o relying on hacks like suppressing the %files section.
Bonus if it checks the suppressed package %files for installed files that need to be skipped even if "not packaged" so as to not error out.
Simo.
On Sun, 28 Nov 2010, Simo Sorce wrote:
On Sun, 28 Nov 2010 12:15:52 +0200 (EET) Panu Matilainen pmatilai@laiskiainen.org wrote:
On Sun, 28 Nov 2010, Kevin Kofler wrote:
Panu Matilainen wrote:
The draft release notes are at http://rpm.org/wiki/Releases/4.9.0
- This change:
| Packages with no files can now omit the %files section and still have | packages generated. is going to make it a PITA to conditionalize the building of subpackages, and it's going to break several existing KDE specfiles very badly (and with no warning!): RPM will silently generate empty subpackages where none is wanted.
More precisely, when we wanted to conditionalize or comment out the creation of a subpackage (e.g. in kde-l10n for languages which are currently not available), what we did so far was to %if out only the %files section for the subpackage, not %package or things like %post, and this would reliably omit the subpackage. Now we'll have to %if out ALL sections referring to the subpackage: %package to prevent the subpackage from being built, and all other sections referring to it because they'll error out if the %package is not there.
This change can be reconsidered.
Wouldn't it be better instead to create a specific directive to disable unwanted subpackages ?
Something like: %suppress <subpackagename>
This would make it clear what the author of the RPMs wants to do w/o relying on hacks like suppressing the %files section.
Bonus if it checks the suppressed package %files for installed files that need to be skipped even if "not packaged" so as to not error out.
Not a bad idea at all, although I'd guess a better syntax would be a boolean enable/disable tag similar to AutoReq etc. That'd allow nice integration with build conditionals, such as
%bcond_without foo
...
%package foo BuildRequires: bar-devel Summary: ... BuildPkg: %{with foo}
- Panu -
Le dimanche 28 novembre 2010 à 12:15 +0200, Panu Matilainen a écrit :
On Sun, 28 Nov 2010, Kevin Kofler wrote:
Panu Matilainen wrote:
The draft release notes are at http://rpm.org/wiki/Releases/4.9.0
- This change:
| Packages with no files can now omit the %files section and still have | packages generated. is going to make it a PITA to conditionalize the building of subpackages, and it's going to break several existing KDE specfiles very badly (and with no warning!): RPM will silently generate empty subpackages where none is wanted.
More precisely, when we wanted to conditionalize or comment out the creation of a subpackage (e.g. in kde-l10n for languages which are currently not available), what we did so far was to %if out only the %files section for the subpackage, not %package or things like %post, and this would reliably omit the subpackage. Now we'll have to %if out ALL sections referring to the subpackage: %package to prevent the subpackage from being built, and all other sections referring to it because they'll error out if the %package is not there.
This change can be reconsidered.
I use this bit too though I'd rather have an explcit way to kill a subpackage rather than relying on empty %files
On 11/26/2010 12:20 PM, Panu Matilainen wrote:
It's that time of year again, although there seems to be an off-by-one bug in the calendar system causing some inconsistency in the timing wrt last year :P http://lists.fedoraproject.org/pipermail/devel/2009-November/042339.html
Anyway, before going to beta and starting the inevitable Fedora Feature process, we'd like some extra preliminary testing to catch out any major issues early on.
The alpha isn't supposed to eat your system alive or anything, but proceed with appropriate cauting, backing up the rpmdb etc, as usual.
The draft release notes are at http://rpm.org/wiki/Releases/4.9.0 and Fedora compatible SRPM(s) can be found at http://laiskiainen.org/rpm/srpms/
In particular, I'm interested in feedback on the new, pluggable and enhanced dependency extration system. Documentation is scarce at the moment but some background and examples can be found here: http://laiskiainen.org/blog/?p=35
Note that the current SRPM is missing gstreamer plugin, cups driver and automatic "devel-symlink" dependency generation, on purpose: the highly application-domain specific gstreamer + cups bits can now be fully moved out of rpm to gstreamer-devel etc, eliminating the need for embedding python inside /bin/sh scripts and such to avoid extra dependencies. The devel-symlink generation will stay in rpm but will probably change somewhat, it can be handled in a more generic fashion now.
Please report any oddities found, preferably to rpm.org Trac at http://rpm.org/newticket or rpm-maint list (or here for fedora-specific discussions/suggestions etc).
P.S. Pjones, before you ask ;) The much wanted ordering-only feature is not in the alpha, but is likely to make it into beta. The patch itself is fairly trivial and non-intrusive, we're just trying to figure sane spec syntax for it (discussion ongoing on rpm-maint)
- Panu -
Hello, I tried rebuild RPM on F-14. New RPM doesn't find all provides as it should. Example: RPM 4.9.alpha rpm -qp --provides perl-CGI-3.50-1.fc14.noarch.rpm perl-CGI = 3.50-1.fc14
RPM from koji: rpm -qp --provides perl-CGI-3.50-1.fc15.noarch.rpm perl(CGI) perl(CGI::Apache) = 1.01 perl(CGI::Carp) = 3.45 perl(CGI::Cookie) perl(CGI::Fast) perl(CGI::Pretty) = 3.46 perl(CGI::Push) perl(CGI::Switch) = 1.01 perl(CGITempFile) perl(CGI::Util) = 3.48 perl(Fh) perl(MultipartBuffer) perl(utf8) perl-CGI = 3.50-1.fc15
I suppose RPM was looking for all strings 'package' in source code. Could you look at it? As test SRPM you can use: http://mmaslano.fedorapeople.org/review/perl-CGI-3.50-1.fc14.src.rpm
Thank you, Marcela
On Mon, 29 Nov 2010, Marcela Mašláňová wrote:
On 11/26/2010 12:20 PM, Panu Matilainen wrote:
It's that time of year again, although there seems to be an off-by-one bug in the calendar system causing some inconsistency in the timing wrt last year :P http://lists.fedoraproject.org/pipermail/devel/2009-November/042339.html
Anyway, before going to beta and starting the inevitable Fedora Feature process, we'd like some extra preliminary testing to catch out any major issues early on.
The alpha isn't supposed to eat your system alive or anything, but proceed with appropriate cauting, backing up the rpmdb etc, as usual.
The draft release notes are at http://rpm.org/wiki/Releases/4.9.0 and Fedora compatible SRPM(s) can be found at http://laiskiainen.org/rpm/srpms/
In particular, I'm interested in feedback on the new, pluggable and enhanced dependency extration system. Documentation is scarce at the moment but some background and examples can be found here: http://laiskiainen.org/blog/?p=35
Note that the current SRPM is missing gstreamer plugin, cups driver and automatic "devel-symlink" dependency generation, on purpose: the highly application-domain specific gstreamer + cups bits can now be fully moved out of rpm to gstreamer-devel etc, eliminating the need for embedding python inside /bin/sh scripts and such to avoid extra dependencies. The devel-symlink generation will stay in rpm but will probably change somewhat, it can be handled in a more generic fashion now.
Please report any oddities found, preferably to rpm.org Trac at http://rpm.org/newticket or rpm-maint list (or here for fedora-specific discussions/suggestions etc).
P.S. Pjones, before you ask ;) The much wanted ordering-only feature is not in the alpha, but is likely to make it into beta. The patch itself is fairly trivial and non-intrusive, we're just trying to figure sane spec syntax for it (discussion ongoing on rpm-maint)
- Panu -
Hello, I tried rebuild RPM on F-14. New RPM doesn't find all provides as it should. Example: RPM 4.9.alpha rpm -qp --provides perl-CGI-3.50-1.fc14.noarch.rpm perl-CGI = 3.50-1.fc14
RPM from koji: rpm -qp --provides perl-CGI-3.50-1.fc15.noarch.rpm perl(CGI) perl(CGI::Apache) = 1.01 perl(CGI::Carp) = 3.45 perl(CGI::Cookie) perl(CGI::Fast) perl(CGI::Pretty) = 3.46 perl(CGI::Push) perl(CGI::Switch) = 1.01 perl(CGITempFile) perl(CGI::Util) = 3.48 perl(Fh) perl(MultipartBuffer) perl(utf8) perl-CGI = 3.50-1.fc15
I suppose RPM was looking for all strings 'package' in source code. Could you look at it? As test SRPM you can use: http://mmaslano.fedorapeople.org/review/perl-CGI-3.50-1.fc14.src.rpm
Yeah, that seems fairly broken. I'll have a look, thanks for testing and reporting - this is just the kind of stuff I want to find out /before/ this hits rawhide :)
- Panu -
On Mon, 29 Nov 2010, Panu Matilainen wrote:
On Mon, 29 Nov 2010, Marcela Mašláňová wrote:
Hello, I tried rebuild RPM on F-14. New RPM doesn't find all provides as it should. Example: RPM 4.9.alpha rpm -qp --provides perl-CGI-3.50-1.fc14.noarch.rpm perl-CGI = 3.50-1.fc14
RPM from koji: rpm -qp --provides perl-CGI-3.50-1.fc15.noarch.rpm perl(CGI) perl(CGI::Apache) = 1.01 perl(CGI::Carp) = 3.45 perl(CGI::Cookie) perl(CGI::Fast) perl(CGI::Pretty) = 3.46 perl(CGI::Push) perl(CGI::Switch) = 1.01 perl(CGITempFile) perl(CGI::Util) = 3.48 perl(Fh) perl(MultipartBuffer) perl(utf8) perl-CGI = 3.50-1.fc15
I suppose RPM was looking for all strings 'package' in source code. Could you look at it? As test SRPM you can use: http://mmaslano.fedorapeople.org/review/perl-CGI-3.50-1.fc14.src.rpm
Yeah, that seems fairly broken. I'll have a look, thanks for testing and reporting - this is just the kind of stuff I want to find out /before/ this hits rawhide :)
To follow up on this one: dependency extraction for perl modules is just plain broken in the alpha due to a dumb thinko/typo kind of thing. Additionally there's an unforeseen interaction with 'rpmdeps' use (which the filtering macros rely on) which causes some further breakage in some cases, including this.
Both are easy enough to fix though, I'll push an updated snapshot in a day or two.
- Panu -
On Tue, 30 Nov 2010, Panu Matilainen wrote:
On Mon, 29 Nov 2010, Panu Matilainen wrote:
On Mon, 29 Nov 2010, Marcela Mašláňová wrote:
Hello, I tried rebuild RPM on F-14. New RPM doesn't find all provides as it should. Example: RPM 4.9.alpha rpm -qp --provides perl-CGI-3.50-1.fc14.noarch.rpm perl-CGI = 3.50-1.fc14
RPM from koji: rpm -qp --provides perl-CGI-3.50-1.fc15.noarch.rpm perl(CGI) perl(CGI::Apache) = 1.01 perl(CGI::Carp) = 3.45 perl(CGI::Cookie) perl(CGI::Fast) perl(CGI::Pretty) = 3.46 perl(CGI::Push) perl(CGI::Switch) = 1.01 perl(CGITempFile) perl(CGI::Util) = 3.48 perl(Fh) perl(MultipartBuffer) perl(utf8) perl-CGI = 3.50-1.fc15
I suppose RPM was looking for all strings 'package' in source code. Could you look at it? As test SRPM you can use: http://mmaslano.fedorapeople.org/review/perl-CGI-3.50-1.fc14.src.rpm
Yeah, that seems fairly broken. I'll have a look, thanks for testing and reporting - this is just the kind of stuff I want to find out /before/ this hits rawhide :)
To follow up on this one: dependency extraction for perl modules is just plain broken in the alpha due to a dumb thinko/typo kind of thing. Additionally there's an unforeseen interaction with 'rpmdeps' use (which the filtering macros rely on) which causes some further breakage in some cases, including this.
Both are easy enough to fix though, I'll push an updated snapshot in a day or two.
Okay, there's now an updated snapshot fixing this and some other issues (mono dependency extraction was probably broken too): http://laiskiainen.org/rpm/srpms/rpm-4.8.90-0.git10730.1.src.rpm
- Panu -
"PM" == Panu Matilainen pmatilai@laiskiainen.org writes:
PM> In particular, I'm interested in feedback on the new, pluggable and PM> enhanced dependency extration system. Documentation is scarce at the PM> moment but some background and examples can be found here: PM> http://laiskiainen.org/blog/?p=35
Unfortunately laiskiainen.org isn't responding for me at the moment, so I can't check the actual packages, but could you comment on whether rpm-builds dependency list will be changing as a result of this? Because if so we'll have to work through a round of build failures as things which used to be in the buildroot purely due to rpm-build might no longer be there. I'm thinking of perl in particular.
- J<
On Mon, 29 Nov 2010 10:15:47 -0600 "Jason L Tibbitts III" tibbs@math.uh.edu wrote:
"PM" == Panu Matilainen pmatilai@laiskiainen.org writes:
PM> In particular, I'm interested in feedback on the new, pluggable PM> and enhanced dependency extration system. Documentation is scarce PM> at the moment but some background and examples can be found here: PM> http://laiskiainen.org/blog/?p=35
Unfortunately laiskiainen.org isn't responding for me at the moment, so I can't check the actual packages, but could you comment on whether rpm-builds dependency list will be changing as a result of this? Because if so we'll have to work through a round of build failures as things which used to be in the buildroot purely due to rpm-build might no longer be there. I'm thinking of perl in particular.
It's working now.
On Mon, 29 Nov 2010, Jason L Tibbitts III wrote:
"PM" == Panu Matilainen pmatilai@laiskiainen.org writes:
PM> In particular, I'm interested in feedback on the new, pluggable and PM> enhanced dependency extration system. Documentation is scarce at the PM> moment but some background and examples can be found here: PM> http://laiskiainen.org/blog/?p=35
Unfortunately laiskiainen.org isn't responding for me at the moment, so I can't check the actual packages, but could you comment on whether rpm-builds dependency list will be changing as a result of this? Because if so we'll have to work through a round of build failures as things which used to be in the buildroot purely due to rpm-build might no longer be there. I'm thinking of perl in particular.
I don't expect changes to rpm-build's dependencies for the time being. The pluggability just makes it /possible/ to add new things without dragging them in as dependencies or jumping through nutty hoops to avoid them.
At some point (maybe for F16, I dunno) we might want to look at pushing some of the current dependencies like perl out to perl-related packages etc, but that's not an immediate goal.
- Panu -
Panu Matilainen schreef op vr 26-11-2010 om 13:20 [+0200]:
In particular, I'm interested in feedback on the new, pluggable and enhanced dependency extration system. Documentation is scarce at the moment but some background and examples can be found here: http://laiskiainen.org/blog/?p=35
All mingw32 packages in Fedora contain these set of instructions in the .spec files:
%global _use_internal_dependency_generator 0 %global __find_requires %{_mingw32_findrequires} %global __find_provides %{_mingw32_findprovides}
Does this new dependency extraction system make these kind of instructions obsolete?
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?
The macros %{_mingw32_findrequires} and %{_mingw32_findprovides} are mentioned in the file /etc/rpm/macros.mingw32 which is part of the mingw32-filesystem package. Both refer to a small shell script which uses the i686-pc-mingw32-objdump tool to extract dependency information.
Kind regards,
Erik van Pienbroek
On Tue, 30 Nov 2010, Erik van Pienbroek wrote:
Panu Matilainen schreef op vr 26-11-2010 om 13:20 [+0200]:
In particular, I'm interested in feedback on the new, pluggable and enhanced dependency extration system. Documentation is scarce at the moment but some background and examples can be found here: http://laiskiainen.org/blog/?p=35
All mingw32 packages in Fedora contain these set of instructions in the .spec files:
%global _use_internal_dependency_generator 0 %global __find_requires %{_mingw32_findrequires} %global __find_provides %{_mingw32_findprovides}
Does this new dependency extraction system make these kind of instructions obsolete?
The above still works with the new rpm version.
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.
- Panu -
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.
Regards,
Erik van Pienbroek
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 -
devel@lists.stg.fedoraproject.org
-
Erik van Pienbroek -
Jason L Tibbitts III -
Kevin Kofler -
Marcela Mašláňová -
Nicolas Mailhot -
Panu Matilainen -
Peter Lemenkov -
Rahul Sundaram -
Simo Sorce -
Susi Lehtola