[gentoo-amd64] Re: firebird and qt

[Duncan]

Горлов Максим Викторович <sheridan@×××××××.ru> posted
200801211143.52447.sheridan@×××××××.ru, excerpted below, on  Mon, 21 Jan
2008 11:43:41 +0300:

> why firebird support disabled in qt?

> [ebuild     U ] x11-libs/qt-4.3.3 [4.3.2-r1] USE="cups dbus doc examples
> gif jpeg mng opengl pch png postgres qt3support sqlite3 ssl tiff zlib
> -accessibility -debug (-firebird) -glib -mysql -nas -nis -odbc -sqlite
> -xinerama" INPUT_DEVICES="-wacom" 0 kB

> how i can enable it?

When you see it in parenthesis like that, it's either because it's being 
removed (in an upgrade or remerge, your current version had the USE flag, 
the to be merged version no longer has it), or because it's profile-
masked.

In this case it'd be profile masked.  Grepping the cascading profile tree 
reveals that the base profile has firebird listed in use.mask.  Looking 
therein reveals the following starting on line 143:

# Diego Petten.. <flameeyes@g.o> (4 Jan 2007)
# Mask the flags for PHP that are available only on x86
[snip]
# Shared with amd64
[snip]
firebird

So it's masked in base, and would be unmasked in the x86 and amd64 
profiles, only for some reason it's not for amd64.  Now, the same grep 
turned up a hit in the amd64 profile changelog, from early 2007 as well, 
referencing bug 156885[1] but no hit in use.mask.  The bug is on firebird 
1.5 series and amd64, while only 2.x (which the bug says is fine on 
amd64) appears in the tree now, so it should be fine.  firebird-2.x is 
even marked stable on amd64.  However, apparently the use-mask fell thru 
the cracks since it's inherited from the base profile and amd64 simply 
hasn't unmasked it for their profiles yet.

Actually... it's rather more complex than that.  Some more bugs to look 
at: [3 4 5].  The gist according to [4] appears to be that amd64 removed 
the entry from their use.mask, but didn't realize the base use.mask entry 
was there (or maybe it was added later).

So it appears it /should/ be OK to use, despite the mask.  I'd suggest 
filing yet another bug asking them to put an entry /unmasking/ it in 
amd64's use.mask, referencing this thread on gmane[2] with all the above 
notes to hopefully make it easier to follow what happened.  Also note bug 
187532 [4] specifically and point out that removing the entry didn't have 
the desired effect due to the entry in base's use.mask, mentioning 
specifically that it's NOT a dup of that bug for that reason.  (Or, you 
could comment on that bug and hope that it's reopened, but if you didn't 
file the bug and aren't a dev, you're depending on someone else to see 
the comment and reopen it since you can't, and that may or may not 
happen.)

OK, there's two loose threads remaining to tie up.

First, this may or may not be an issue for you, but it's something to be 
aware of:  The licensing for the firebird database isn't compatible with 
the GPL used by qt.  Depending on exactly what you are doing with qt, 
this might be an issue (you're OK just running it on your machine, but 
can't distribute the resulting qt as compiled against firebird).  See yet 
another bug: [6].

Second, how do you work around that use-masking?  First, create the 
/etc/portage/profile subdir if necessary.  Basically, this subdir acts as 
a profile that cascades on top of the existing cascading profiles in the 
tree as pointed to by /etc/make.profile, and you can create any profile 
entries here you need, reversing or adding to the entries in the existing 
cascading profile.  In this case, we need an entry reversing that 
use.mask entry in the base profile, so create a use.mask file here, and 
add an entry negating the previous firebird entry like so (putting the 
name and location of a file in a comment at the top helps sort things out 
if the file ever ends up in lost&found after an fsck):

# /etc/portage/profile/use.mask

# unmask the firebird USE flag as it should work
# bug 187532
-firebird

FWIW, the portage manpage mentions negating use.mask entries like the 
above, and mentions that subdir for overrides, but the two mentions are 
far enough apart it's quite possible someone could fail to connect the 
dots appropriately.

That should do it! =8^)

---
References:

[1] http://bugs.gentoo.org/show_bug.cgi?id=156885

[2] http://comments.gmane.org/gmane.linux.gentoo.amd64/12323

[3] http://bugs.gentoo.org/show_bug.cgi?id=187922

[4] http://bugs.gentoo.org/show_bug.cgi?id=187532

[5] http://bugs.gentoo.org/show_bug.cgi?id=186791

[6] http://bugs.gentoo.org/show_bug.cgi?id=200284

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@l.g.o mailing list