On 05/10/2010 03:49 PM, Tom "spot" Callaway wrote:
The Fedora Packaging Committee will meet on Wednesday, May 12, at
its
regular time of 16:00 UTC, and in its regular location of
#fedora-meeting. Here is the expected agenda:
As I'd likely not be able to
attend, here are my preliminary votes:
This is useful as
"cooking recipe" for packaging such packages, but feel
this is too specialized to be suitable for guidelines.
OK as an "inofficial" appendix, but not OK as part of the main FPG.
Basically OK, except of the naming proposal (libpic-foo.a etc.).
-1 in its current shape, because this would
a) break with tradional usage of static libs.
b) would require intrusive works on some packages' sources.
+1 with the library naming scheme removed.
-1 ...
superfluous bureaucracy.
As repeatedly
said, I am opposed to using %{_isa} in general, because I
consider it to be redundant to library paths and to only be adding bloat.
Also, the current proposal seems "uncooked", to me
(E.g. I don't understand when the author want packagers to use %{_isa}
or not).
Proposal: Have the author rework it and table it for now.
Should you insist on voting on it, count me as "-1".
* Correct existing definitions of RPM Macros in guidelines to match
current reality:
https://fedoraproject.org/wiki/PackagingDrafts/RPMMacros_sharedstatedir_o...
It's step into the right direction, but if being pedantic, there are
mistakes in this draft:
* autoconf variable datarootdir is missing
(Off head, I don't know if rpm meanwhile has adopted it. It's in
autoconf for many (10?) years)
* _lib is not an autoconf variable.
Its documentation should be moved into the "non-autoconf" section.
Otherwise OK.
+1 with the changes above applied, 0 otherwise.
=====
If there is something else that you feel should be on the agenda for
this meeting, please feel free to let us know.
We need strict definitions (or at least documentation) of which packages
to expect in each specific distro's buildroots, shouldn't we already
have them (ATM, I can't find them).
Background: In recent days, I have been observing "package-rebuild
errors", seemingly originating from some packages having been removed
from buildroots. As I was rebuilding packages maintained by other folks,
I don't know for how long these build error have been present (they did
not cause build aborts, but caused the packages to be "mis-built").
Ralf