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:
As always, this list is pulled from
http://fedoraproject.org/wiki/Packaging/GuidelinesTodo (which embeds the
table from
http://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo ):
ASCII Naming Guidelines (spot) :
http://fedoraproject.org/wiki/PackagingDrafts/ASCIINaming
Were you going to add something about working with other distros if
transliteration is not done upstream? (Jesse's post:
https://www.redhat.com/archives/fedora-packaging/2008-March/msg00169.html
)
Looks sane
Do we want the Group tag information? I know we've decided group is
irrelevant in the main guidelines.
In the Jar Expansion (rare) item:
- I'd remove (rare) from the title.
- Should we remove the debug_package %{nil} workaround since there's
another workaround listed and we want debug packages?
For item #3, does it matter which of the three directory names is used?
Should we pick one?
I'd split item #5 into two as the first sentence deals with package
naming and the second with directory locations.
#5b -- In the second part of 5, I'd list both the arch directory and
arch-independent directory and I'd list them with macros:
{_datadir}/package-name & %{_libdir}/package-name
#5b -- Should we have plugins install into subdirectories owned by
openoffice.org-core? ie: %{_libdir}openoffice.org and
%{_datadir}/openoffice.org. Note that %{_datadir}/openoffice.org
doesn't currently exist, so it's a new directory that
openoffice.org-core would need to provide.
Structure: I'd reorder the items so they match the order in which one
encounters them in the spec file:
5a 6 4 2 3 7 5b 3 1
Having short titles instead of just numbers might also be good.
Panu, can buildroot go into rpmbuild?
I'd rather the page listed what should be added as the primary point of
reference. That will also justify its existence. For instance, if the
purpose is collaboration between packages, why list internal provides?
What makes the example of kuipc/cernlib(devel) internal? It is for one
package to require another so I don't understand the distinction.
rh_status in example superfluous?
lsb header-- how actually works would be better in a noteclass (but that
might not support formatting)
lsb header example first instead of summary?
Trim this from ScripletSnippets?
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#head-1fc158879a...
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
I still see open questions here.
-Toshio