On Wednesday 30 July 2008 09:26:59 Mark Wright wrote:
> > I don't know about those two: it looks like those are fairly recent
> > additions to Nevada, as neither dillon nor my regular
> > workstation )nv70 and nv83) have them.
>
> That is easy:
>
> # Filter out libgphoto2 and gphoto2 if SUNWgnome-camera is installed.
> ifeq (GNOME2,$(shell pkginfo SUNWgnome-camera | cut -f 1 -d' '))
> PSPC_FILES := $(filter-out libgphoto2.pspc,$(PSPC_FILES))
> PSPC_FILES := $(filter-out gphoto2.pspc,$(PSPC_FILES))
> endif

Applied in slightly modified form, thanks.

(The modification is: filter-out can take more than one word to filter out at 
once, which IMO improves clarity because each group of things to filter out 
maps to one filter-out call)

There is an issue with the system SUNWgnome-camera and that is that it is 32-
bit only (the same applies for lots of Free Software builds that show up in 
SUNW packages). So we couldn't -- can't -- have any FOSS* stuff depend on 
libgphoto unless those FOSS packages in turn go to 32-bit only.

We keep hitting things like this in our quest to be both 32- and 64-bit clean. 
There's no 64-bit libusb, so if *we* wanted to build libgphoto2 in a sensible 
way ourselves, we would have to do libusb as well. There follows another 
cascade of packages. And HAL, too, is 32-bit only.

Since the KDE build *right now* is 32-bit, this isn't a fundamental 
restriction to getting KDE on the desktop *right now* but it does raise two 
questions:

1) is it realistic to aim for 64-bitness given Sun's apparent reluctance to 
support it in the existing software stack?

2) do we really care about 64-bitness?

[ade]

Reply via email to