Re: [VETO] GPG and EFS lossage in package update description

I want to question the veto... :-) Joachim> * packageGuide.content: Describe EFS problem with Extended Passive Joachim> Mode (solved in efs-1.33). Describe how to handle package index Joachim> verification if Norbert's key is not installed. MS> The description on how to solve the EFS problem is misleading, and MS> won't always work. Instead, you need to tell people to *disable* MS> passive mode by specifying an appropriate flag (-A on FreeBSD) in MS> `efs-ftp-program-args'. What you're suggesting creates a mismatch MS> between the mode EFS believes the ftp client to be in and the one it's MS> actually in. Then this is an EFS error. Using the Customize interface to turn on the variable 'efs-use-passive-mode should never result in `a mismatch between the mode EFS believes the ftp client to be in and the one it's actually in.' Customize is the end-user interface for configuration and must not produce inconsistencies for such an elementary case. As a proposal, EFS should use `passive on' and not `passive' to turn on passive mode. Or it may use `ftpmode passive'. Old clients, e.g. Solaris ftp, will choke on all those commands anyhow; this way it will work with modern ftp clients. Since you're the EFS maintainer, do you accept this email as a bug report?:-) Furthermore, I would propose to add another option 'efs-use-active-mode where one can turn on active mode explicitly. That enhancement is independent from the bug report above. But back to my proposal how to change the XEmacs Web Site. Explaining how to customize 'efs-use-passive-mode is easier then explaining how to customize 'efs-ftp-program-args (one click vs. click on INS and adding the string). Please note also that I didn't write to `Save' the passive setting, just to Set it. I want it just for this session; after updating efs it will just work anyhow. Since you know EFS by far better than I do: In which situations will my proposal not work? In case of BSD and Linux clients, EFS seems to handle this mismatch quite fine, and correctly fetches the package index. Where does it go wrong? I know that there may be problems if firewalls don't support active ftp, but only passive ftp. Do you think of them, or do you have other situations in mind? In particular: Do you know about specific ftp clients, where (1) the message `Entering Extended Passive Mode' appears _and_ where (2) sending `passive' (and thus entering active mode in reality) will lead to errors while fetching the package index? Remember, this is a description of a minimal workaround, not a resolution. It shall help people who want to update the packages of their SuSE or Feodora or from-wherever-they-got-it XEmacs, and it shall describe the most easiest way possible. It's not for people who install XEmacs themselves; the new Sumo tar-ball doesn't have that problem. And after update of efs, the workaround is not needed any more anyhow. IMO, the focal point is the following: We have 100,000s of XEmacs installations out there who are part of Linux distributions. It might be that more people get their XEmacs from there than from the XEmacs download. For many of these people, the description how to update packages simply doesn't work: they cannot update packages _at_all_, due to old EFS not handling the passive mode. (Many folks on xemacs-beta might not even know this as they run current XEmacs versions.) But we _need_ to give those users an _easy_ way to update; and the Web Site should reflect the most easiest, working way. I tried to describe a workaround -- if you veto it, please submit a better description. Just letting all those users in the situation that they cannot update any package at all, is no solution -- IMNSHO. Cheers, Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod(a)acm.org Kranichweg 1 Tel.: +49-6074-861532 63322 Rödermark, Germany Fax: +49-6074-861531