On Wed, 2002-10-23 at 07:26, Stephen J. Turnbull wrote:
Ville> Hmm, now I don't understand; site-packages?
Ville> Why introduce a new build dir
It's not new. site-packages have been around for pretty much as long
as the package system has. There needs to be a place for stuff that
sys admins can put local/3rd party packages. This where I've put my
own stuff for about 3 years now. When I'm ready to check in to CVS, I
just move it over to {xemacs,mule}-packages.
Ah, I see. "grep site-packages *" in packages/ produces no hits, that's
what made me wonder what you're talking about.
Ville> and not use unsupported/stephen for that?
It never occurred to me to use unsupported that way. I think of
unsupported/stephen as a staging area for my experimental packages
that others might like to play with, not as where I put somebody
else's beta packages that I'm testing.
...and I think of it pretty much as the opposite :). Anyway, it
obviously can be used for both of purposes.
BTW, I'm not sure I like the idea of anything we distribute,
including
unsupported/, defaulting to installing in site-*/.
I'm fine with changing this, just go ahead if it bugs you.
unsupported-packages?
But strictly speaking, IMHO we're not distributing anything under
unsupported/. It's stuff that just lives in our CVS, and doesn't even
get checked out if using the "packages" module, as the instructions
advise to do. (Too bad a subsequent "cvs update -d" will bring it into
the working dir. CVS modules suck sometimes.)
I don't see why XEmacs shouldn't have the same rights and
responsibilities as any other fully capable operating system. :-)
Hey, where's my "Boot XEmacs" CD... :)
--
\/ille Skyttä
scop at
xemacs.org