Re: Thoughts on XEmacs packaging (was Re: Making docdir configurable)

sb> [It's time, I think, to move this to xemacs-beta] Yes. sb> Michael Sperber <sperber(a)informatik.uni-tuebingen.de&gt; writes in xemacs-review(a)xemacs.org: >>sb> Michael Sperber <sperber(a)informatik.uni-tuebingen.de&gt; writes in xemacs-review(a)xemacs.org: sb> ... sb> These are strong words. If things are really this fucked up then they sb> should be fixed. I did not mean to offend anyone. I don't disagree with the way things have gone. It's just that package organization questions are generally very difficult. (Debian and RedHat spent inordinate amounts of time creating giant general-purpose packaging tools, and they still suck.) Thus, things could be much worse. sb> All of the changes I've made have been fairly conservative. If we sb> really needed to, it wouldn't take more than perhaps a day to undo sb> everything and return to a 20.4-style source tree. I pray we do not do sb> this. Recall that we went through that exercise to create 20.3. Absolutely. That was also my main goal in reimplementing startup path searching. Still I got yelled at massively for even the tiniest change (justifiedly in some cases), moreover, I was made responsible for package system design issues I had had no part in. This makes me not very eager to go through something much worse. I've tried posting design notes before implementing things, and still got yelled at when the beta came out that actually had them. I tried being responsive to people's suggestions in response to my designs, and then got yelled at for not implementing something which turned out to be my original design noone had bothered to read carefully. At this point, to do anything, I need some backing from at least one of the major maintainers. I'll share all my thoughts, but I don't want to have to respond to every single nitpick. sb> I suppose. I really, really don't like code that decides what to do sb> based on an Emacs version. Wrong wording on my part. You want a package to be able to say that it doesn't run in a certain Emacs, based on arbitrary criteria. A toolbar package (or whatever) might not make sense in a tty-only Emacs, for instance. sb> That would be a departure from how things worked in XEmacs 20.x and sb> that is why I didn't do it that way. Right, and I agree with that decision. sb> I am not adverse to changing things now, and so long as the sb> programming interface remains the same or very similar, it sb> shouldn't be a lot of work to migrate to a different layout. I guess I need to know what exactly the programming interface really is. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla