Ralf Angeli writes: > Since the version distributed with the XEmacs package collection is > unsupported upstream, one could conclude that the XEmacs project is > taking care of support for that version. In that case you should at > least add a disclaimer of the different support address and change the > bug reporting address.
I've already announced my intention to do that. I gather you're not aware of that? However, the issue of the addresses was discussed with Uwe Brauer when he volunteered, who indicated at the time that we should point our auctex-* aliases at AUCTeX. That may have been an uninformed decision, but at the time we believe that it would be possible to have an up-to-date package without too much trouble. However, if this is so annoying to you, there must be lots of them. I'm curious, why aren't those users coming to XEmacs? Don't you tell them what the right place to report bugs is? Or what? > Apart from that I don't really understand why the XEmacs project is > distributing an outdated version of AUCTeX (or any other package for > that matter). What don't you understand? That users like the convenience of the packages for updates when available, and of the SUMOs for initial installation? Well, let me tell you: users like the convenience of the packages for updates when available, and of the SUMOs for initial installation. Or don't you understand that our resources for updates are finite and mostly user-contributed, thus there are lags? Well, let me tell you: our resources for updates are finite and mostly user-contributed, thus there are lags. I'm really tired of repeating those facts. Yes, I know that this thread just started on AUCTeX. But surely you can see the 13 References that preceded your post as well as I can? Nor is it like Debian stable or even Fedora core manages to keep all of its packages up to the minute. Or GNU Emacs, for that matter, except when it can absorb an upstream package so that the Emacs version *is* the current version by definition. *All* distros make this compromise. As for AUCTeX in particular, you quoted the reason already: >>> AUCTeX is free software. Uwe Brauer, who maintains the XEmacs >>> package of AUCTeX, values an XEmacs package enough to do the work In addition, I'm happy enough with the AUCTeX we've got for my own use. > It sheds a bad light on their package system If so, why aren't we hearing that from our users? What we hear from the users is that they like packages, and the ones who want an up-to-date AUCTeX get it from AUCTeX. Win-win, as far as I can see. The fact is that the only people who complain about the XEmacs package system in general are upstream package developers. Of course users whose favorite package is out-of-date report it as a bug, but they rarely get very upset when offered the choice of maintaining the XEmacs package or maintaining their own installation of upstream by hand. There are some clumsy aspects, those are bugs too---but that doesn't stop most users from using the package system. > In addition it leads to the constant stream of unpleasent > discussions we've seen around the AUCTeX package. It doesn't. The unpleasantness is entirely due to personality conflicts. The ESS package has very similar technical issues, and the current maintainer there decided to withdraw the package. Of course things were a little tense because of the goal conflict, but basically the relationship has been amicable and the discussions productive. And there are others in that project who disagree with the current maintainer; I'm sure something will be worked out when resources become available. That happened a while ago, but a related thread happened this week, too. AUCTeX doesn't have that option because AUCTeX refuses to help with the XEmacs package (as we define it; I know you have something that unpacks into the same places, but it doesn't serve *our* goals), and AFAIK the XEmacs maintainer wishes to keep trying to update the AUCTeX package. Someday we'll succeed. > So the XEmacs project could _at least_ change the support > addresses. Please. AFAI knew, Uwe was considered part of the AUCTeX project. He didn't ask for a change, so the aliases didn't change. *You* didn't explicitly ask for a change, either. Not that I know of. Don't say it should be obvious; it wasn't, especially not in the midst of the firestorm that David enters the XEmacs lists with almost every time. So, I've changed the aliases. Fixing addresses in the package itself will have to wait a day or so. > If they feel they cannot provide sufficient support for a package > they distribute as an outdated version, they should consider > refraining from distributing it. *We get no bug reports from users.* It's as simple as that. If and when we start getting bug reports, there will be something to consider. > The situation would be a bit better if the XEmacs package system > allowed for the inclusion of additional locations for package download > similar to something like apt. We've had that forever. It's clumsy, you can only have one site active at a time AFAICT, and the interface for users to add sites is undocumented (AFAIK). I've already proposed fixing that, too, in this thread. It's technically not that hard, I think. A major overhaul of the package UI almost happened 3 years ago, but Steve Youngs wanted to do it his way, then it never got done. > implementing such a feature is likely not economically sensible > because I doubt there are many XEmacs packages built outside of the > XEmacs project. I'm sure several would be, actually. VM already is. x-symbol would be (unless upstream has abandoned it). If the facility were available, I suspect several projects would want to do it; it's not like the typical DESTDIR install would be very hard. One problem is that that kind of sensible, everybody-wins suggestion has rarely been made. _______________________________________________ auctex-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/auctex-devel
