On Wed, 2008-03-19 at 18:33 -0400, Tom "spot" Callaway wrote:
This goes out specifically to the Fedora Packaging Committee
Members,
but is certainly open for comments from all.
We've got a lot of drafts that are queued up for next Tuesday's meeting,
so it would be very helpful if you read them all well in advance:
Due to the fact,
I'll likely not be able to attend on Tuesday,
preliminary comments/answers/votes interspersed.
Already replied in a
separate mail.
Generally OK, but I am missing a
section on perl subdirectory directory
ownership.
My vote: 0 without such a section, +1 with such a section.
Also, I do not agree upon the section on "Makefile.PL vs. Build.PL",
but ... this is nothing new. I would prefer leaving the choice to the
maintainer and not to explicitly recommend Build.PL.
0, I don't understand
what this draft is trying to say and which
problems it is trying to solve. Could you explain?
0, no opinion on
this.
OK for FC
> 9, not OK for FC < 9
The unopkg concerns still apply
- /usr/bin/unopkg is not available for FC < 9
Updating the FC8/7 packages to provide them won't help, because users
might not have "updates" installed.
- Also, I am not sure if /usr/bin is the appropriate location to install
unopkg. /usr/sbin/ might be more appropriate.
+1.
OK as a recommendation for Fedora < 10, but should not be made mandatory
before Fedora 10 (or even later), IMO.
Should this proposal be accepted, rel-eng should implement it into all
packages during a mass-rebuild, may-be accompanied with rpm's upstream
implementing it as "default buildroot" into (FC10's) rpm.
-1
Not clear enough. Many packages apply virtual provides not covered by
these lists (e.g. alternate package names, obsoletes/provides, legacy
provides etc.) This proposal doesn't specify which class of virtual
provides it is aiming at.
+1, Seems OK to me.
I don't have the Java Guidelines draft on the list yet, but I
hope that
it will be ready by next Tuesday:
http://fedoraproject.org/wiki/PackagingDrafts/Java 0, for now, no opinion on that.
I don't see any obvious mistake/flaw,
but I am not sufficiently knowledgeable on java to be able to comment on
details.
Ralf