Hi, I've reported packages I've found missing so fare (right now), but I may add some in the future.
Don't get me wrong I don't blame EPEL for their effort, I'm so happy that it exists that I'll do my best to help at least by reporting bugs in the most constructive way I can. For now, I'm unable to help building as 100% of my spare time is dedicated to bring back to life SysteImager and OSCAR Cluster. For those who knew SystemImager, the new upcoming release is light years ahead the last stable release (full rewrite of the imager that can install an run a linux distro without rebooting). But there is still lots of work to do before I can release it. As I said, I'm in the process of removing most perl/python code that is too hard to maintain (migration between releases, shebang changes, inconsistency of toolboxes across distros, ...) in the benefit of a web GUI with push events (php + json). I'll soon solve the perl-Qt dependency. Of course, once released, I'll maintain EPEL package for EPEL6,7,8 , all supported fedoras and SuSE (and hopefully Debian world if I find time to sort out dracut/initramfstools conflicts and have some kind of automatic dependency checking like the rpm-helpers we have for php/perl/python/binaries/...) All SystemImager is based on sgml docbook V4? Files and I know this is pretty old, but I have no knowledge to migrate that to something that is up to date and modern. Any tips? Should I move to mxml? (as I need to find an alternative for missing docbook-utils-pdf needed here: https://github.com/finley/SystemImager/tree/initrd-from-imageserver-and-dont-package-initrd/doc/manual_source). Best regards, Olivier. Le 30/09/2019 14:08, « Petr Pisar » <ppi...@redhat.com> a écrit : On Mon, Sep 30, 2019 at 11:45:24AM +0000, LAHAYE Olivier wrote: > For docbook-utils-pdf, I don't understand why redhat did drop it, and > I wonder how can EPEL publish only the missing part without breakage if > redhat updates the 1st half. This is the burden of a downstream distributor. You never know what the upstream breaks. One way EPEL wants to solve it is repackaging the complete package as a Modularity module and then providing it to users as a non-default module stream so that users who need it can explictly enable it and consume the packages from EPEL instead from CentOS/RHEL. > For perl-QT, Fedora-30 still ships it: https://pkgs.org/download/perl-Qt (v4.14.3-17), but I know it's not well maintained. It's there by a mistake. (A late Qt rebase broke it and nobody removed it from the distribution.) It even cannot be installed. -- Petr _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
