Hi,

On Thu, 7 Oct 1999, John Darrow wrote:
> I've got a lot of local patches in my pkgsrc tree to fix packages which
> make improper assumptions (directly including X11BASE in install rules,
> etc.) which are not valid with xpkgwedge.  Send-pr'ing these patches has
> been on my one-of-these-days list for a long time now...
> 
> I also discovered quite a while ago the necessity of an XPKGBASE variable
> (which you recently added and then backed out), as there are a few
> non-USE_X11BASE packages which depend on USE_X11BASE packages...

Can you please sum up the problems solved with your patches? 

There are concerns that we will have to patch many packages for cases when
xpkgwedge is used that will work fine (unpatched) without xpkgwedge. (and
vice versa, that packages that are made without xpkgwedge will break with
xpkgwedge installed, increasing workload on pkgsrc developers to fix bugs
etc.)

Do you thinkg that putting the XPKGBASE variable back (and reworking all
packages to make use it) to prevent most of these problems?

(I'm just too much of a coward to say we should put in XPKGBASE and patch
all our packages, just to find out later that there's some other problems
(besides the ones already known: appdef files, ...))


> Unfortunately, the presence of xpkgwedge is quite a political issue. Some
> people don't want to have to teach non-packaged software to look in
> LOCALBASE for added X11 includes, and thus don't want xpkgwedge.  Others
> (including myself) would rather keep everything that is package-based in
> LOCALBASE.  (Among other things, this encourages building packages for the
> non-packaged software with patches to fix non-portable assumptions, which
> then makes it easier for others to install the packages without having to
> deal with the same problems...)

You're absolutely right. In the whole process to make xpkgwedge work we
should not forget, though, that it is an _option_, with some known risks
(non-packaged software not working, ...), that we should not enforce on
people per default.


> <rant>
> I, especially, think that X11BASE is already hard enough to deal with
> sanely due to its non-hier(7)-conforming setup, and especially the whole
> X11BASE/lib/X11 directory, which contains some things which belong in etc,
> some share, possibly some libexec and libdata, and some var...  Adding
> packages to that mess is just, IMO, The Wrong Thing.
> </rant>

Well, we could of course fix X, make it conform to hier(7) and then go and
pkgize it, like it was back in the 1.3 days (and before!)... 

The question is what raises more incompatibilities with existing
software. :-)


 - Hubert

-- 
NetBSD - Better for your uptime than Viagra