On Mon, Oct 7, 2019 at 3:21 PM Tomasz Kłoczko <kloczko.tom...@gmail.com> wrote:
> On Mon, 7 Oct 2019 at 13:28, Jindrich Novy <jn...@redhat.com> wrote: > >> Hi Tomasz, >> >> > On top of removing perl-generators which add for mc proper perl modules >> dependencies for >> > patchfs >> >> Can you please elaborate on the above? patchfs works for me despite >> missing perl-generators? This is not raised by me but the following request >> from an user: >> ----- >> Hi Jindrich, >> >> I did a minimal install of CentOS 8 with mc and saw that it pulls in perl >> due to (I guess) BuildRequires: perl-generators in the spec file. I >> looked at mc upstream and they do not list perl as a requirement: >> https://github.com/MidnightCommander/mc/blob/master/doc/INSTALL >> >> Did I miss something or is perl no more needed? I'd be happy to file a >> BZ, just let me know. >> > > Without installed perl(File::Temp) perl module when someone will enter > into patch to use patchfs it will be be not working. > If you want to fix that you should try to rewrite patchfs perl backend > script in POSIX sh. > I'm almost sure that using perl in patchfs or zipfs is obverkill. > > As well rpmfs is written is perl (many years ago when I've rewrote rpmfs > scrip it was using only POSIX sh with rpm as only external command .. > however in meantime someone made here some "progress"). > Thanks, the BR: perl-generators is now added back. > > Next time instead using you proven packager privileges at least please try > to contact someone who actively is maintaining some package. > Note I'm still official fedora maintainer of mc: https://src.fedoraproject.org/rpms/mc > BTW mc. > Also I do not understand why FC31 release comity ignored my objection to > push mc 4.8.23 to fc31 since it core dumps sometimes few times per hour of > active use. > You commented on the F29 update (not F31) here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-e3e2bc7747 and failed to reply to my comment. >From end user point of view difference between mc 4.8.22 and 4.8.23 are > negligible. > I have opened ticket with that issue > http://midnight-commander.org/ticket/4023 > Thanks. Also please reply to my questions you deleted from previous email - we need to be sure what to do WRT aspell in mc and whether it makes sense: > now we have pollution of the mc static dependencies by add aspell-en. > mc does not need aspell-en but aspell does because aspell to work properly needs at least > some dictionary. Adding Requires of aspell-en fixes this: https://antonishapsas.wordpress.com/2019/01/18/midnight-commander-no-word-lists-can-be-found-for-the-language-en/ which is very annoying and lot of users are complaining about it. Every time you edit a file you need to confirm the "No word list can be found for language en." For aspell vs aspell-en you suggest mc be dependent on aspell directly? Is there any bug requesting Requires: aspell-en from aspell? Other option is just to disable spellchecking as a whole. I'm in doubt anybody is using it. For me it is important we get rid of annoying UX issues encountered every time when user edits a file. I'm happy to discuss any possible/more appropriate ways to address this instead of this workaround. Tomasz, regarding to patches you added downstream: mc-default_setup.patch - Can you propose this upstream? mc-python3.patch - Can you propose this upstream? mc-rpm.patch - Can you propose this upstream? mc-spec.syntax.patch - Can you propose this upstream? Please do not pollute downstream with these patches - better way is to do a PR upstream - once merged we can do a release candidate in rawhide with the upstream checked-out tarball. Extensive patching downstream without any upstream involvement requires lots of maintenance/forwardporting. Thanks, Jindrich
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org