Red Hat Bugzilla – Bug 1480922
python-pelican is shipped with an old version of feedgenerator.py which leads to unexpected behaviour
Last modified: 2017-08-16 07:00:51 EDT
Description of problem:
Pelican 3.7.1 shipped by Fedora 26 fails to generate <content> tags (which contain the full post, as opposed to <summary> tags which are generated) in the Atom XML output of the website, despite Pelican's documentation claiming that <content> tags should be present.
This happens because Fedora uses an old version of feedgenerator.py (*afaik* provided by ython2-django-1.10.7-1.fc26.noarch), despite Pelican's build instructions requiring feedgenerator 1.9+.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. pelican-quikstart a new site
2. create one post
3. add "FEED_ALL_ATOM = 'feeds/atom.xml'" in the pelicanconf.py file
4. generate html output
feeds/atom.xml contains only <summary>
It should also include <content>.
A lot of debug output here: https://github.com/getpelican/pelican/issues/2202#issuecomment-322002331
The version of pelican installed with pip works as expected, and uses feedgenerator-1.9.tar.gz.
Pelican contributor says that pelican's fork of feedgenerator.py has diverged from django's bundled module, so maybe packaging pelican's version might be necessary
>> Is pelican's feedgenerator.py just a standalone package for django's feedgenerator.py, or is it a fork?
> Originally just a standalone package, but since then, it may have diverged from Django's bundled version.
I can confirm this issue. With the Fedora 26 pelican version the atom feeds don't contain any content.
The version from pip works fine.
Thus, this is a regression to the official Pelican release and its documented behavior.
See also #1421185 for another issue that is caused by Fedora's choice to replace the Pelican feed-generator package with the incompatible django one.
feedgenerator describes itself as
Standalone version of django.utils.feedgenerator
I see your issue. I would argue, forking and changing something instead of contributing back is not so nice as well. Django could benefit from enhancements as well....
This can be proposed back to the pelican developers, but from a Fedora POV, are we going to keep this package in a broken state?
since there is no feedgenerator in fedora yet, there's not much I can do about it right now.
I was wondering if the features that break because of the dependency are considered serious enough to temporarily withdraw the package, so that users default to using the pip version.
My 2 ct here:
- pip happily overwrites rpm package installed contents. The result is random. (That's going to change in f27)
- It depends on your usage, if the rss feed containing not all elements is "mission critical"
- If you want feedgenerator in fedora, please help with the review. I noted in the other bug, I'm fine with depending on feedgenerator (once in Fedora).
- From a general perspective, I disagree with pelican upstream to fork parts of Django; disagreement is fine, we all can grow on the arguments.
I'm not sure in what ways I can help with the review, never done this before, but I downloaded the spec file and I'll try to test if the package works.