"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; writes: I would agree. Would it be difficult to switch from handcrafted make files with handcrafter Local.rules makefile includes, into, say, autoconf? Each package subdir could have it's own ./configure. This would make it possible to build individual modules (e.g. cvs co mail-lib + ./configure + make) which I think is very useful -- right now I can't really point anyone that want to test new stuff in the `mail-lib' package to the CVS repository without giving instructions on how to build and install it. It would also be possible to actually TEST individual modules. Right now I only use M-x byte-compile-file RET to see warnings/errors. Forcing everyone, that want to work on, or test stuff, to checkout entire xemacs-package subverts the whole modularized idea, IMHO. Packages are a can of worms. You need dependencies, and the longer the system are in use, the dependency system gets more and more complex. Silly Ideas Dept: use .rpm or .deb's? They have sufficiently complex dependency systems, and more importantly; OTHER people spend time improving the packaging system. It's possible to setup multiple rpm databases, and it works even as non-root users.

On 20 Feb 2001, Steve Youngs wrote: If I get bored next weekend, I'll take a stab at it. :-) RPM (and I think also DEB) run on more than linux. They aren't much different from a tar-ball with some versioning and installation instructions. The problem with sticking to tar.gz or coming up with our own system is that it will require quite some work to match the packaging functionality one expects in a package handling system. Note that I'm not saying that switching to RPM won't mean work, but in the long run it might be nice to use some packaging system.

Even my group in Red Hat won't ship RPMs to customers. RPM doesn't work on enough platforms. In addition, why should you have to install RPM in order to install XEmacs? -sew

SJT> (1) There should be a mechanism at top level (I mean in SJT> Local.rules) to omit building a package which is in the tree. SY> True. But we also need a way to prevent someone from SY> excluding a package that is required by another package that SY> they do wish to build. I guess that would come under the SY> banner of "dependencies" huh? Yes. And it's more complicated than you indicate. I may have more disk space than time, and simply check out the whole of xemacs-packages for convenient reference etc. But as long as I have the installed packages, I can build against those. (This is basically the point that's being made by Hrvoje in the "GPL violation in packaging" thread.) That's OK, and should be allowed for local admins. But you (ex oficio XPRE) want to build in a controlled way (at least that was Steve B's theory), and therefore you should build all packages against the current state of CVS which allows (near) replication (subject to eg that byte-compiler bug which affected your XEmacs but not the stable version). SJT> (2) We need a safe way for maintainers who are making big SJT> changes to their packages to check them in gradually. This SJT> is especially true where xemacs-packages is the primary SJT> repository for the package source, or where the package SJT> maintainer may primarily work with GNU Emacs, not XEmacs. SY> I disagree with this. Why should there be any need for SY> xemacs.org to be the primary repository for any external SY> package? What's wrong with the external package maintainer's SY> local machine, or if [s]he wants somewhere public, how about SY> SourceForge? There's no need and nothing wrong. But I don't see why it needs to be physically separate, it can be logically separate == a CVS branch. It is much easier to merge if they are located in the same repository, because CVS can do much of the diff tracking for you. Paul Kinnucan is finding physically separate repositories a painful experience. If you can tell me that's technically fairly easy to solve, OK. But I don't really see it, and personally I wouldn't want to do it that way. That is, I would encourage people who see advantages to working from SourceForge to do so (and hope that VA Linux's stock price doesn't go negative). But they should also be able to work from cvs.xemacs.org. And some packages like mule-base, xemacs-base, and xemacs-devel, surely belong on cvs.xemacs.org. SY> That way, hopefully, the mistakes get made on SY> cvs.sourceforge.net, not cvs.xemacs.org. cvs.xemacs.org is our primary development repository. I see no reason why someone who thinks of XEmacs as the home environment for his package shouldn't use cvs.xemacs.org. Should we have physically separate repositories for the development branch and the stable branch of the core? SY> I disagree with these two points (see my comments above). Your opinion of course has an awful lot of weight. Especially if you do the implementation, as seems likely. :-) SY> Exactly what is the way that GNU handles packages? I don't SY> want to dismiss something without knowing what that something SY> is. GNU doesn't handle packages at all. Either it's in the base (for example, the Gnus distributed with GNU Emacs 20.7 is well over two years old now), or it's the local admin's problem entirely. Conflicts? Dependencies? Bu-wha-ha-ha-ha! SJT> This is a long-term project, but we need to do something SJT> about better dependency handling. SY> Agreed. And this brings me back to something that has been SY> mentioned quite a few times - This is a job for, dum dum SY> dummmm; Capt^H^H^H^Hautoconf (amongst other things). I don't think so. autoconf suffers from the same problems that I mentioned for dpkg and rpm: what a _developer_ expects them to do is build most of the dependencies automagically. Whether we you a homegrown dependency tracker or one of the generic PMS's, there just aren't any tools for building dependencies for Lisp libraries. Not in rpm, and not in autoconf. It's not a magic solution: autoconf is great for C and stuff because it's got all those preexisting macros to look for features and breakage. But for Lisp I suspect we'd need a bunch of our own. One thing I know Martin has spent a lot of time on is autoconf mantainence. He regularly updates config.sub and config.guess, cleans out cruft and so on. But it's not easy, because our ac.local is a real horror show (thus have I heard, I'm not an autoconf guru). It would be even worse for the packages (in a sense, and certainly on a smaller scale) since none of the macros are written yet. Nor does autoconf help the users track dependencies at runtime. I'm not objecting to autoconf as a technical solution. I don't like it personally, but I'm not going to tell Perl users to rewrite their scripts in Python and I'm not going to tell the XPRE not to use autoconf if that's the tool he thinks is best. It will work. It's just going to be a lot harder to get right in the first place, and more work to maintain, than you think until we get all the little tools built to autogenerate dependencies. IMHO YMMV and all that. SJT> (4) There is no simple way to maintain just one's own SJT> package; you have to check out all the dependencies as well, SJT> and build them too. SY> So, how is that different from any other software package that SY> has dependencies? Very. With a C program, all you need are the .so's in /usr/lib and the .h's in /usr/include. With an XEmacs package, the .el's etc in /usr/local/lib/xemacs/xemacs-packages will not serve. You need all the Makefile stuff up to the top, for sure, plus the CVS layout of the source tree for any dependencies. Eg, I don't have the GTK+ or GNOME sources or build scaffolding, but I can build gtk-xemacs. SJT> But this doesn't work very well if somebody screws up, since SJT> the build stops in the middle. SY> Would it be better if the build continue on regardless? I SY> don't think so, and my reason for that is simple: Yes, but the dependency system should catch this. At present it is not possible to depend on "sufficiently recent" dependencies. If it were, you wouldn't be able to install the new target if a dependency failed to build. In any case, my point is not to continue a broken build. My point is that breakage in irrelevant packages (ie, not requested by the admin and not required by any requested package or its dependencies) should not stop the build. SY> Yes it might take a bit of time to initially check out the SY> xemacs-packages module. But after that all they need to do SY> when the wish to update their package is: Maintainers should not make work for other people. If it's necessary, yes, require it. But the maintainer should always be looking for ways to reduce the imposition on others. And remember, "other people" here is not restricted to just the package maintainers, for whom having access to the same environment you use is important. It's also just regular users, who may have an interest in a particular package, but otherwise use a Linux distro's packages for the core and SUMOs. IMO, of course, and I'm not saying you should downgrade your own priorities. But this is also an investment that has some payoff for you. Anything that modularizes the system from the point of view of people != you also probably helps you in terms of fault isolation, reducing FAQs, etc. I'm trying to present some factors I would consider in your shoes, that's all. I am sure that you will evaluate them differently, but it would be a shame if I didn't mention them and you got bit in the ass by surprise. SY> There is no need for them to do a complete build of the entire SY> tree, a 'make distclean && make autoloads' will suffice. Make autoloads can get broken. SJT> If that's what we need, that's what we need, but this is a SJT> lot of effort and resources on the part of an external SJT> package maintainer. SY> Yep, it's what we need and it's not much effort and hard disk SY> space is cheap these days. Not much effort? That's not what Paul Kinnucan -- or you! -- is saying about the JDE mess. If it really was just a matter of disk space and make World, that would be OK. But it's not really that simple. "Packages won't build" is one of the common subjects on xemacs-beta these days. Nor is hard disk space necessarily cheap for everybody in the world, as Hrvoje has pointed out repeatedly. And as for "what we need," I'm talking about in the long run, and not about the setup you inherited, which is showing problems with scalability. Again, I'm not saying I know what to do, and since it looks like you're going to spend a lot of effort on it, you should do it in the way the makes you job most effective. I'm just offering advice on what I think would be useful in accomplishing some of the stated goals, and what I think would benefit people other than you. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."