Description of problem: Please branch and build weasyprint for epel9
Will you be able to branch and build weasyprint in epel9?
Hi Navneet, the main problem with WeasyPrint is that upstream versioning mostly follow other web browsers: There is no particular stability guarantee. Basically each user must verify if a newer version of WeasyPrint still generates comparable PDF output. For EPEL this is a bit of a problem as maintainers should not push incompatible upgrades. Now the situation might be easier with WeasyPrint 54+ as we don't need cairocffi anymore (dependency tree more manageable, easier to fix bugs for WeasyPrint developers) but certainly we won't be able to upgrade WeasyPrint often (if ever) in EPEL 9. What are your thoughts about this? Newer WeasyPrint versions are easy to install via virtualenv+pip...
Hi Felix, Sorry about the late reply here. In our environment, we use yum only to install python packages as well. We don't use pip currently :(. I'm ok even if we can't upgrade it often. Basically, I'm moving our environment to be based on el9 and currently, I'm ending up using fc34's version, if I can get it in epel9 itself then I don't need to maintain it separately.
Same argument here, maintainance via dnf (RHEL EPEL 9) is easier and already established via satellite. For pip upgrades we would need another (yet to implement) mechanism.
Dependant python packages which do not exist in EPEL: pydyf pyphen And maybe tinycss2 in a newer version.
I'll need WeasyPrint on EPEL 9 in the next months as well so I will come up with something. However my time is really limited and I'm still hesitant of "locking in" a WeasyPrint version forever. For example, I just had to switch to WeasyPrint v62 for PDF/A support and so a "permanently frozen" version in EPEL9 is not really attractive to me (thus I can't spend my work time on that). So I would need someone else coordinate the EPEL 9 version (testing, checking version requirements for tinycss2 et al with respect to other EPEL packages). Maybe Orion is interested as he already maintains tinycss2 in epel. My current plan is to create a COPR repo like "weasyprint-el9-v62" which would hold all packages required to install weasyprint v62.x for EPEL9. Once I need a newer package, I would just create a new repo with a later version but if someone is willing to invest some time in getting something into EPEL proper, I'm certainly willing to help (bonus points for new contributors because I always try getting more brains involved in Fedora).
I do not understand your concerns about increasing WeasyPrint versions. Weasyprint is a leaf package (?) so soname bump (more-or-less) don't play a role (according to package rules) I can help you using my private fedora account, but I am only a sunday packager. :)
> Weasyprint is a leaf package (?) so soname bump (more-or-less) don't play a role (according to package rules) I see a potential problem for EPEL users: Whenever I push a new WeasyPrint version, the generated PDF might be different and I consider this a breaking change, thus not acceptable for EPEL. That is also the reason why new major versions for WeasyPrint are added only to Fedora rawhide.
Well, as it happens I need WeasyPrint in EL9. Previously I would have distributed this outside of EPEL but seems like there are more users interested in WeasyPrint for EPEL and not much concern about being stuck on an old version.
FEDORA-EPEL-2024-b93ff26026 (python-pydyf-0.10.0-1.el9, python-pyphen-0.13.2-1.el9, and 1 more) has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-b93ff26026
FEDORA-EPEL-2024-b93ff26026 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-b93ff26026 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2024-b93ff26026 (python-pydyf-0.10.0-1.el9, python-pyphen-0.13.2-1.el9, and 1 more) has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.
Works for me. Thank you