Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 144507 - Change to noarch, various other improvements
Change to noarch, various other improvements
Product: Fedora
Classification: Fedora
Component: epydoc (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Matthias Saou
Fedora Extras Quality Assurance
: Patch
Depends On:
  Show dependency treegraph
Reported: 2005-01-07 15:43 EST by Ville Skyttä
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-13 15:34:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Suggested specfile patch (2.78 KB, patch)
2005-01-07 15:43 EST, Ville Skyttä
no flags Details | Diff
Menu entry for epydocgui (169 bytes, text/plain)
2005-01-07 15:44 EST, Ville Skyttä
no flags Details

  None (edit)
Description Ville Skyttä 2005-01-07 15:43:28 EST
Suggested improvements to epydoc:

+* Mon Dec 20 2004 Ville Skyttä <ville.skytta at iki.fi> - 2.1-3
+- Change to noarch.
+- Get Python site-packages dir from distutils, should fix x86_64 build.
+- Require python-abi and tkinter.
+- %%ghost'ify *.pyo.
+- Fix man page permissions.
+- Add menu entry for epydocgui.

Patch and desktop entry attached.
Comment 1 Ville Skyttä 2005-01-07 15:43:28 EST
Created attachment 109494 [details]
Suggested specfile patch
Comment 2 Ville Skyttä 2005-01-07 15:44:07 EST
Created attachment 109495 [details]
Menu entry for epydocgui
Comment 3 Matthias Saou 2005-01-07 16:16:51 EST
Simply great.

I had already fixed the noarch and x86_64 build in my own spec file,
but I had hardcoded the "lib", as it seemed pretty normal to me to
have the files there instead of "lib64", as it is a noarch package.

I'll commit your changes, just a few questions if you can answer them
to enlighten me a little :
1) Is the hardcoded "fedora-" prefix to the desktop file the current
way of doing things?
2) Same question about the added X-Fedora.
3) Do you have a pointer to the site-packages thingy?

Last, I saw a thread about the .pyo %ghost'ing on fedora-devel, but
still didn't get that far in my post-holidays mailing-list discussions
catching up.
Comment 4 Ville Skyttä 2005-01-07 16:54:16 EST
fedora- and X-Fedora in .desktop files is what we've always done in
fedora.us.  I don't think there are any real guidelines for those, nor
that it matters much with the current FC menu configs.  Perhaps change
to extras- and X-Fedora-Extras sometime?

site-packages thingy: get_python_lib is AFAIK the most "official" way
of retrieving the site-packages dir(s); that's what setup.py's usually
use under the hood.  distutils.sysconfig.get_python_lib() returns the
site-packages dir for arch-independent python extensions, and
distutils.sysconfig.get_python_lib(1) for arch-dependent ones. 
Currently, the only situation where this matters is noarch packages
built on x86_64, which will break if this stuff used incorrectly; on
ix86 both of the above calls return the same dir.  I personally also
anticipate that some day the arch-independent site-packages dir will
move to /usr/share.  Did that answer your question? :)  See also
spectemplate-python.spec in fedora-rpmdevtools.

Shipping *.pyc and %ghost'ing *.pyo is in my opinion the best general
approach even if it tends to clutter specfiles a bit because:
- Not shipping *.pyc would mean that users running python apps without
write access to the site-packages dir (or someone creating the
compiled *.pyc beforehand) would result in on-the-fly compilation ->
possible performance issues.
- Shipping *.pyo is useful for only a very small fraction of people ->
- Not shipping nor %ghost'ing *.pyo (or *.pyc) means that if one runs
a python script using these extensions (a "python -O" script for
*.pyo), the generated *.py[co] would be left behind when erasing the
package.  The -O1 thing in %install is an easy way of getting the
*.pyo generated during the build, ready to be %ghost'ed.
Comment 5 Matthias Saou 2005-01-13 15:34:37 EST
OK, I've applied the patch. Thanks again.

Note You need to log in before you can comment on or make changes to this bug.