On Thu, 17 Aug 2000, Richard Rauch wrote:

> > > Bringing NetBSD up to XFree86 4.x, I think, might best be done by putting
> > > it in a package for now.  This way, it would be ``officially available''
> > 
> > Before that, it might be a good idea to "packagize" NetBSD's X.
> 
> I don't entirely see why 4.x can't be ``packagized'' first, and then only
> packagize 3.3.6 later, if there's a need.  Mind, I'm spectacularly good at
> missing the obvious.  (^&  That's not to say that I can't see any value to
> having them both as packages.

I do. It would be a maintenance nightmare to make a standard XFree
package with hundreds of little patch-?? files. Moreover, it would be
a step backwards, since we already have xsrc in-tree.

> Could a packaged 3.3.6 (or whatever) XFree86 make it in time for 1.5?

No chance. This is still at the "pie-in-the-sky" stage. Perry's
objection--the run-time dependencies being clobbered--is a serious
one, but I have some ideas about that. We'll have to revisit this later.

> But, a packaged 4.x could be done (and used)
> ``anytime''---as soon as the package was ready.

Don't go there. How do you intend to maintain the patches? Like I
said, we already have an in-tree xsrc, so the only good choices are
branch, or wait.

> (Limited tests unaminously suggest that 3.3.6 binaries run under 4.0.
> But, I've only tried a handful of binaries, and haven't really pushed
> them.  And, in any case, anecdotal evidence is hardly satisfactory.)

That's what I thought, but it's good that you verified that. It means
we can probably update xsrc painlessly once 4.x settles down.

> > Next question is how to break it down. I would be inclined to break
> > out the shared libs from the xbase sets, and go with the same old
> > names for the remaining sets (xbase, xcomp, xcontrib, xfont, xserver).
> 
> I have no strong feelings on this, since I don't know how NetBSD's XFree86
> distribution differed from XFree86's own distribution in the past.  I _do_
> note that 4.0 has Xdoc, Xhtml, Xjdoc, Xman, and Xps relating to
> documentation.  Perhaps an xdocs set would be worth considering?

Good suggestion. We could do that even without pkgizing xsrc.

> > Maybe we should have an "xlocal", too? I'm also not sure about the
> > non-shared libs in xcomp--we don't have anything like that in pkgsrc.
> 
> a) What would go in xlocal?

There's one program now in xsrc/local. There could even be more, one
day, such as graphical package tools.

> b) Why should our package system care if a library isn't shared?
> (Consider me clueless on this count, if it's fairly obvious.  (^&)

We wouldn't want static libs from one version and shared libs from
another in the same directory, for obvious reasons. Usually, if we
break the libs out of a package, we break them all out.