"Stephen J. Turnbull" <[EMAIL PROTECTED]> writes: >>>>>> "Uwe" == Uwe Brauer <[EMAIL PROTECTED]> writes: > > Uwe> It is most unfortunate that xemacs, ui, pui does not manage > Uwe> 3rd party pkg, as does dkpg and rpm. > > Nope, it has nothing to do with "fortune"---it's by design. pui is > about helping XEmacs volunteers provide consistent support for > packages we distribute.
XEmacs volunteers. Too bad the package developers might be the better choice at times. > The burden of being pui-compatible on most 3rd parties is either > 100MB of disk space for the package tree and a few minutes to update > CVS before distributing a new binary package, or less than 100KB of > space and at most a couple hours figuring out how to get all the > infrastructure into the right place relative to your source. Sorry, but you are presuming that the package developer is going to use the XEmacs package CVS as his sole repository after that. And "at most a couple of hours figuring out" is not what I call an invitation for participation. > If somebody wanted to get this right and make it more convenient, > I'm sure XEmacs people would be willing to help with it, You are always sure about that. And it is always a surprise for you when few actually do and when one has to dig up third-party people to help with something they themselves don't actually know. XEmacs developers have their own priorities and limited resources, and dealing with the situation is not made easier by you pretending it is different. > but 3rd party developers and users prefer to wait for somebody else > to do it. > > This is all irrelevant to AUCTeX; AUCTeX is not "most 3rd parties", > or at least it wasn't in the last public release. If it's now > possible to release a binary package of AUCTeX, then things have > changed a lot. Not really. This situation is not particularly new, there was always the offer to do this, it is just that I have recently formalized it with a Makefile target. This Makefile target is not black magic: it just creates a separate tree, calls `configure' and `make'` with the right options, then packs the results. What has been done recently was to create a setup that permits leaving the preview-latex TeX files in the package tree. But that was just to cater for preview-latex, which never previously had been an integral part of AUCTeX, and which never had any XEmacs packages around. > Nevertheless, I don't think it's appropriate to put a package built > by a non-XEmacs process into our FTP site; that would implicitly be > a promise that it will interact correctly with our tools, Get real. The AUCTeX packages built by the XEmacs processes have so far _all_ broken the promise to work correctly, because of various reasons, code changes, version numbering problems and so on. Downstream can't provide any help for it because they are not AUCTeX developers and are not acquainted well enough with the code to know what problems might be caused by themselves, and upstream has a hard time figuring out what problems are caused by downstream instead of the original work. It's like repairing clockwork with mittens on. > and would require us to keep track of whether that package continued > to work with any future changes in the package infrastructure. I can tell you that _your_ package of AUCTeX will break with future changes in the package infrastructure. AUCTeX setup is not trivial: moving files relatively in the tree will break things, since various files are set up to find others in relative file paths. And that means that the upstream configure scripts (which can't even be checked into the XEmacs package CVS or be called in the build process) have to be told the _final_ package layout in order to generate the right configuration files. Moving things around afterwards is going to break things. > That's not our job IMO. If you weren't so lousy at _what_ your job is, we wouldn't have to do most of it ourselves in the first place. In the time and effort it takes to disassemble an AUCTeX XEmacs package from upstream into its pieces, rearrange them for CVS, make sure that removed files get deleted, generate the appropriate XEmacs metafiles and so on, one could quality check the complete upstream package 5 times over. We are not doing all the work of assembling an XEmacs package ourselves because we want to have fun. We are doing it because there is nobody around downstream that both would and could do so, namely an XEmacs person. At least Uwe _would_ do so, and because he does not have the skill set for "could" as well, we cater for it upstream as well as we can. And providing a completed working package as an "example" is pretty much "as well as we can". So Uwe's job indeed is to figure out how to convince the XEmacs build structure to produce a package identical to what the Makefile target in AUCTeX already does. If you decide to change your package layout around and change your build scripts accordingly, the downstream AUCTeX will immediately stop working because it _depends_ on the relative structure of the file layout told to `configure' for finding its files. There is no sensible place where one can change this except in the upstream Makefile and other files that can't even be checked into the XEmacs package CVS tree because they would conflict there. Whatever. It seems like the course AUCTeX needs to take for its XEmacs users is to provide a separate XEmacs package upstream and tell people to use that. We certainly will not stop providing Uwe or whoever else with whatever help we can for producing a basically unsupported downstream package, but in my book you are using him as a fig leaf to pretend everything in the XEmacs package server policies is beautiful. So I am not even sure he is actually doing you a favor. And it is not a one-time job he is doing, but something that continues to cause work in future, work taking time and effort, work that can go wrong, and work that is actually redundant since packages are already produced upstream. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum _______________________________________________ auctex-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/auctex-devel
