http://fedoraproject.org/wiki/PackageNamingGuidelines#head-ced15ebed5e5ed...
I'd like to clarify the perl-* section of the package naming guidelines
a bit. Currently, it talks about stuff like "the CPAN name of the perl
module" and colons and dashes.
What's "the perl module"? While this question can often be answered by
deciding the "main" module in a CPAN module distribution, it's
unnecessary and doesn't really match the practices already applied for a
long time (for example perl-libwww-perl).
Since the unit of CPAN packaging is really a CPAN module _distribution_,
I think that section of the should be simplified to say that the
packages should almost always be named perl-$CPANDIST. The only
exception would be the rare cases where a CPAN module distribution needs
to be chopped into smaller subpackages; in those cases the split ones
should be called perl-$CPANDIST-$somethingdescriptive.
Thoughts?

Hi,
As Fedora Extras is speeding up we're starting to see people unearthing
their pet package from RHL 6.x/7.x time and submitting it to extras. It
may be a good idea to add those §s to the packaging guidelines :
1. Red Hat packaging is not always right
FE has stronger packaging requirements than RHL/RHEL/FC, so blindly
copying a RHL/RHEL/FC spec file may not be sufficient (especially if you
rebase older releases).
2. Follow the Filesystem Hierarchy Standard
Always follow the Filesystem Hierarchy Standard rules when choosing file
locations. The FHS (http://www.pathname.com/fhs/) is one standard
everyone seems to agree on.
--
Nicolas Mailhot

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I wonder if anyone has a solution to incorrect path-names in
byte-compiled python packages.
In the normal dist-utils install step within the context of an rpmbuild,
all paths get prepended
/var/tmp/buildroot-.../usr/lib/python2.x/site-packages. This causes
incorrect stack trace information to be shown.
I'd taken to doing byte-compilation in the %post step to fix this, but
I've discovered a much worse effect from this in that all the .pyc and
pyo files thus fall outside RPM control, and when removing the package,
stay in place, effectively negating the removal (although the
translation units are definitely gone...)
Any thoughts?
Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFDPoxdCfroLk4EZpkRAr+FAKCyb/b+q8MRn5Nf5X+x0HUCi6sHBgCcDduj
dhvYknEVuoW7ziQBTEieuKw=
=Dlu+
-----END PGP SIGNATURE-----