One recent addition to Python modules packaging at Red Hat in its Fedora project, is carrying along an additional, and optional structured metadata about the contents of that module (package), held outside of the RPM database
This additional information: egg-info came into Python at Python version 2.3 and following. More may be learned about these eggs at: egg-info (optional extra Python metadata about a Python module).
See: Fedora specifics
This new detail is a two edged sword. On one hand, it provides sufficient information that an ad hoc root level process, for when one using native Python tools that it makes for an easy_install [the skeptic in me suggests it might be 'easier', perhaps, along some skewed axis of metric of goodness]. See also the egg superset, Python setuptools which now work well in RPM-mediated space
Sadly, down this path, modules which are outside of the protections and managae-ability of the RPM packaging system may "easily" and inadvertently be introduced by an incautious admin, and thus introduce of Python code into a otherwise controlled system. This is the horror of a mixed RPM and CPAN system, all over again. As I say, one needs to choose a 'metric of goodness' with care
Incautious use of mixed packaging approaches in turn can lead to possible security and updates headaches. Using such non-packaging system tools can break the SPOT -- single point of truth -- to determine to what versions of binaries a given host is using. From sad experience, this way lies additional work, and madness
But on the other edge of that blade, the egg-info adds descriptive narrative, and cautiously used, increases the usability of a system that does not (ab)use those native installation tools
As noted, the FOSS world has faced this problem before with perl and CPAN. Weak and strong 'includes' versioning and security model questionable @INC 'include' path search practices in Python and perl are well known failings in their community archive models. I faced it recently in a packing push of CRAN modules for R -- hmmm, I still need to file a few bugs upstream to solve some problems I saw in some R module packaging choices that I consider poor ones
There is not a single, objectively 'technically right' way to proceed, but rather just one consistent, or not consistent with packaging system design and usage choices
Fedora helpfully offers a sample stanza to use in .spec files. I cruised my archive of .spec files to see what else turned up
# See if there's any egg-info
if [ -f %{buildroot}%{python_sitearch}/Conch*.egg-info ]; then
echo %{buildroot}%{python_sitearch}/Conch*.egg-info |
sed -e "s|^%{buildroot}||"
fi > egg-info
and later then using the %files stanza's -f file list option
%files -f egg-info
%defattr(-,root,root,-)
%doc LICENSE NEWS README doc/*
%{_bindir}/cftp
...
It appears I need to do some work in my local archive of SRPMs. Never enough hours in the day
